Copy Command

So, why not fix Help and the User Guide?

So I suggest the following description of *copy:

“*Copy with Confirm unset will not overwrite files unless the Force option is used. If Force is used it overwrites existing files whether or not the access and write-protect settings are intended to protect them.

If Newer is specified, to prevent overwriting newer files with older ones, Force is still required to enable any overwriting to occur.

Unless Recurse is enabled *Copy will not create new directories in the destination, nor will it create files in existing subdirectories.

With Confirm enabled most of the above will produce messages and requests to do or skip the particular file or operation. This is tedious if a lot of files are involved.

If you need to overwrite older files with newer ones in a bulk operation, but don’t want to alter protected files, then you need to use the desktop “drag to copy” operation instead, having first, in Configure=>Filer, set the Newer option, and unset the Force option. This tool always uses the equivalent of Recurse, so will create/update subdirectories and their contents. It has the additional advantage of allowing other desktop operations to continue while it works.

The above should probably start with:

“The syntax is *copy <source> <destination> [<options>]

Note that the options if specified must come after source and destination. They are case-insensitive.

*help copy will display the full list of options, and their default state.

The default options are set during startup and are held in the copy$options system variable.

If an option is specified in the command, it overrides the default. If it is specified preceeded by~ (e.g. ~f) then it overrides and negates that option from the defaults, so in this example, ensuring the Force option is turned off. There is no adverse effect to forcing on an option which is on by default, or forcing off one which is off by default. If you are creating obey files to do the copy, it is wise to specify all the options in the state that you require."

====
Comment just for the forum:

The copy$options system variable is defined in Choices:Boot.predesk. I’m not aware of a tool which will alter that value in the file. However the system variable can be changed once the system is running.

Is there a place anywhere on here to suggest updates to the User Guide?

Is there a place anywhere on here to suggest updates to the User Guide?

This shows recent activity. User Guide small corrections

It’s fine once the meaning of the F switch is understood. (F)orce overwrite forces the copy over the file exists warning.

Since it overwrites locked files unexpectedly it is NOT fine.¹ Fix the operation of Newer as Rick says:

I think the question is, if Newer was modified to allow overwriting of non-locked files, as the description suggests, would anybody actually suffer from this? Due to the brokenness, it is quite likely that people have written scripts that use FN (or haven’t realised that their copy failed).

That, I think will fix the general operation, allow the proper use of Force.

Thereafter, scripts written for use on RO5 will may not work on versions < 5

¹ Just because something has been broken for years it does not justify ignoring the brokenness.
I fix things all the time at work and I’ve lost track of the times that people comment on how something suddenly worked better.

As suddenly many older scripts do not work as they used to,

In what way would the presence of an N F option pair in a script be broken by a fixed N option that didn’t need the F in order to do anything?

I think people have established that N does absolutely sod all if F is not present.

I think everyone is aware that with F present then the copy will overwrite any older file including locked files

Statement of fact: a script with N and F present will behave exactly the same way as it always has. Badly with respect to locked files that users thought were protected.

newer scripts being used on older releases (even of RO5) begin to fail in unexpected ways. Badly with respect to locked files.

Shall we revert to the behaviour of everything in RO 5.19?
Nobody wants any of the hundreds of fixes that have occurred since then.

The compatibility issue would be in allowing Newer to work without Force, or adding a new option.

Existing behaviour:
N + F currently required to make N do anything at all

N +F currently overwrites older files AND older LOCKED files as an accident.

Proposed behaviour:
N on its own actually does something – i.e. what Newer is _expected to do, allow older files to be overwritten WITHOUT danger to locked files

N + F overwrites older files INCLUDING LOCKED files – by deliberate act on the part of the script writer

Please take the time to read as written

Good advice when self administered.

Which part of the proposed behaviour breaks an existing script?

Proposed behaviour:
N on its own actually does something – i.e. what Newer is _expected to do, allow older files to be overwritten WITHOUT danger to locked files

N + F overwrites older files INCLUDING LOCKED files – by deliberate act on the part of the script writer

I would endorse this action. My existing scripts would continue to work as before with N + F and any new scripts could use N as for newer files but this might need to check OS version with If Then Else construct for backwards compatibility.

Just needs fixing before some well-meaning but misguided soul starts editing documents to make them describe the broken setup as though it’s meant to be like that.

No clue about fixing it, but it’s somewhere in Fileswitch isn’t it?

Can you softload it for the older OS’s?