Copy Command

See PRM.

F(orce) Force overwriting of existing objects.

Newer is supposed to do that (if newer)

and when we go back a few days Stuart said:

The F switch is used to ignore whether the destination object already exists. [Edit – I’d forgotten that it wasn’t just about locked state

Is it? Isn’t it?

So maybe use this as a start – if I can get textile to accept it without mangling the layout. It will only look right in a mono-spaced font, but I don’t think I can add a CSV file here, which would be the ideal way.

Copy Command does this                                             Filer_Action does this
A(ccess)  Force destination access to same as source {on}          not known
C(onfirm) Prompt for confirmation of each copy {on}                Config sets this
                                                                   Has option only-confirm-deletes if confirm set
D(elete)  Delete the source object after copy {off}                not known
F(orce)   Force overwriting of existing objects {off}              Config
L(ook)    Look at destination before loading source file {off}     not known
N(ewer)   Copy only if source is more recent than destination {off}a newer version always overwrites  regardless of Force setting
                                                                   Requires Force if Confirm is off
P(rompt)  Prompt for the disc to be changed as needed in copy {off}not known
Q(uick)   Use application workspace to speed file transfer {off}   reverse option - make multitask
R(ecurse) Copy subdirectories and contents {off}                   always on
S(tamp)   Restamp datestamped files after copying {off}            always off
sT(ructureCopy only the directory structure {off}                  always off
V(erbose) Print information on each object copied {on}             config
Faster    no equivalent                                            config
                                                                   Menu from window can select slower (report all files)
                                                                   or faster (only report periodically)

The F switch is used to ignore whether the destination object already exists. [Edit – I’d forgotten that it wasn’t just about locked state

Just tested this.

*copy with ~C won’t overwrite – Newer is not involved.
*copy with F~C overwrites.

So the copy command doesn’t overwrite ANYTHING unless Force is set.

Filer_Action always overwrites if C is unset, unless the destination is locked.

In both cases, if Newer is set, an overwrite attempt is only considered if the source is newer than the destination.

What Steve said… and me… and others.

Newer should overwrite if newer, as the description implies.

It’s worth noting, also, that the current (botched, IMHO) implementation does not allow for copying newer files but leaving locked ones alone. The need to Force with Newer just to get it to work is therefore ridiculous.

FilerAction’s way of doing it is much more logical.

FilerAction’s way of doing it is much more logical.

More intuitive certainly. The main weakness with *copy’s operation is that you can’t update a folder while protecting locked files. You either don’t update, or you also change the locked files.

I wonder how much would break if *copy were to be changed to match Filer_Action? !Sysmerge?

The other significant difference is that Filer_Action always recurses into directories. *copy by default only changes the directory specified, and without R it errors if it tries to copy a directory that didn’t already exist.

I sense we’re no nearer “a generally agreed document somewhere which will (tautology warning) definitively define the various behaviours!”

I wait patiently!

I sense we’re no nearer “a generally agreed document somewhere which will (tautology warning) definitively define the various behaviours!”

I think there’s pretty much an agreement on what both the Copy command and FilerAction should do.

Alan has been mapping out what the two actually do

and then there’s the existing documentation…

I have an idea: why not make them both behave the same, both do what they should do and just for a little extra spice that behaviour could go in the documentation.

Yeah, silly boy.

I wonder how much would break if *copy were to be changed to match Filer_Action?

Potentially quite a lot, which is why changing it after 30 years would be a bad idea. Not least because once changed, it would then be impossible for anyone to use *Copy in a distributed script which might need to run on other versions of the OS as well.

Clearly documenting what it does would be the far better option, I suspect.

N should always allow the over writing of an unlocked file with a newer file.

That is one possibility. It is not what happens nor what the documentation says. The N flag prevents the copying of older files, which is a very different thing but much easier to understand.

What we need is a flag (for the command line copy) that allows copying over existing objects separately from the F options which allows copying over locked (and existing) objects. A sort of lower case ‘F’.

The behaviour of the ‘N’ flag in desktop copy with respect to the datestamps of directories (rather than the objects within them) should also be explained. Are the contents of an older directory ignored for example when the ‘N’ flag is set? Some filing systems update the date of the directory when files are added.

The FilerAction already copies recursively and over existing objects, so is fine, just very poorly described in PRM 3-236 as the flags are not described at all and are different from their use in the command line copy.

The N flag prevents the copying of older files

I have been slowly coming to that interpretation.

F options which allows copying over locked (and existing) objects

The F option perhaps should be explained the other way around, copy over existing (and locked) objects.

N is a rider to F.

Copying without F does show a file already exists warning and reports no file copied.

Copying without F does show a file already exists warning and reports no file copied.

Which brings us back to the fact that N is broken, it doesn’t allow Newer files to overwrite unless you include the dangerous F option

N should only look at the date stamps of files, and not directories. The behaviour of directory date stamps across different filing systems (including image filing systems) is very variable, and should not be relied upon.

The underlying reason why this is confusing is that N is meaningless except when overwriting is contemplated. The fact that it still doesn’t overwrite unless F is specified is just plain wrong.

The reason it happens like this is because copy doesn’t overwrite ANYTHING unless F is specified. N should change that, but doesn’t.

The confusion arises because Filer_Action does the opposite, and those among us with less than 20 years of RISC OS experience will have used Filer_Action before using *copy.

I still think *copy could be changed, because any script that specifies the options it needs will still work. Any that don’t specify the options can be edited.

bq. The F switch is used to ignore whether the destination object already exists. [Edit – I’d forgotten that it wasn’t just about locked state]

Is it? Isn’t it?

It is in fact nothing to do with locked state – F must stand for fuzzy memory. If a copy gets to the point of trying to copy a file, having passed tests for older/same datestamp rejection if N specified, not confirming etc. then it will attempt to ensure any target file is unlocked. Take a look at the actual OS_FSControl code, it seemed reasonably well commented as to its intent.

N should only look at the date stamps of files, and not directories

Indeed, and that’s what it does

There are bits of Filer_Action that I haven’t seen documented.

It doesn’t (seem) to make any use of Copy$Options. It’s settings are stored in a file within Boot and set with Configure. Are there any other options that can be put in there which Configure doesn’t make available?

Copy uses A to copy the access settings of the destination from the source. What does Filer_action do?

*copy has P to copy with the case of copying from one floppy to another on a single floppy drive. Filer_Action cannot encounter this case, as source and destination both need to be on screen to start the copy. Does *copy also use this in the case of copying from, for example hard disc to floppy, when the floppy becomes full. Does it ask for a continuation disc?

Option D changes copy to do a move. Filer_action does this if the drag is done with Shift held down.
(If source and destination are on the same drive Filer_Action does a rename. Does Copy do a copy then delete in this case? It can be a lot slower.)

Copy has option L (look at). I don’t know what that does in copy, and I don’t know therefore whether the equivalent needs to be documented in Filer_Action.

Filer_Action cannot encounter this case, as source and destination both need to be on screen to start the copy

Both DO need to be on screen, but may not both be in the same drive at once.

Does it ask for a continuation disc

Of course not – we don’t have files spanning multiple media, and any new disc would have a different label, so the target would no longer be valid.

Copy has option L (look at)

It was intended to allow Copy to take a peek at the destination to see if it had access permission before starting to copy data from the source. Can help to do ~L if copying floppy to floppy using a single drive. Different times, eh?

Anyhow, slightly rewording Steve F, does anyone think it a good idea to change a 34 year old API rather than writing a new one? If so, where do you stop?

Oh look, it is documented in the PRM (OS_FSControl 26)

“It is not possible to choose a combination of flags to perform the same operation as “no confirm” in the desktop, as the desktop will overwrite files without confirmation, but won’t force the overwriting of locked files, whereas this SWI will only overwrite files if it either has force set, or confirm set and gets positive confirmation.”

Oh look, it is documented in the PRM (OS_FSControl 26)

I wonder how many new users will:

A see or know about the PRM

B know OS_FSControl 26 exists

C know it’s relevant to either *Copy or Filer_Action

What matters is what is in the Help, and in the User Guide.

It might be helpful then to say in the User Guide that Force (and other flag combinations) don’t do what you might think coming from other OSes.

The documentation for Copy was severely trimmed between the RO 2 and 3 UGs. Haven’t seen anything later.

The underlying reason why this is confusing is that N is meaningless except when overwriting is contemplated. The fact that it still doesn’t overwrite unless F is specified is just plain wrong.

Yup, agreed 100%

It might be helpful then to say in the User Guide that Force (and other flag combinations) don’t do what you might think coming from other OSes.

Is that a paraphrasing of “it’s broken”? Because that’s the only correct answer.

What matters is what is in the Help, and in the User Guide.

So, why not fix Help and the User Guide? Making an established CLI command behave differently on (some versions of) RO5 compared to the other versions of the OS that are out there seems like a really bad idea, given that it’s actually operating as designed.

does anyone think it a good idea to change a 34 year old API rather than writing a new one? If so, where do you stop?

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).

does anyone think it a good idea to change a 34 year old API rather than writing a new one

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

Obviously (N)ewer only has meaning if overwrite is enabled, with (F)orce.

The Filer configuration tool has a different action associated with Force, which is only about Locked files.

The most that is required might be a little tweak to the documentation or *help.