Copy Command

But that’s not a precise explanation, Alan.

*Copy foo bar ~C

where bar already exists DOES NOT OVERWRITE (unless you use F)

If anything, there ought to have been a separate switch to allow overwriting existing files without further confirmation, leaving F to just override current destination object access. But that was a discussion that needed having 34 years ago.

I see what you mean. I tested using desktop drag and drop.

So for completeness:

Using the desktop filer to copy:
~N~C overwrites files regardless of date
N~C doesn’t overwrite regardless of date.

Using the command line:
~N~C doesn’t overwrite files regardless of date
N~C doesn’t overwrite regardless of date.

Sorry, that doesn’t behave reasonably. They should be consistent.

I can’t make my mind up as to which is wrong though. I’m tending to think it’s the desktop has it wrong – ~N~C shouldn’t overwrite. Alternatively N should not require confirmation in either case.

I remember switching between VMS and RISC OS. Both would prompt for confirmation with Y,N,A,Q

VMS interpreted these as Yes, No, Always, Quit
RISC OS interpreted these as Yes, No, Abandon, Quiet, i.e. the last two are opposites.

Confusing…

I have no idea what the desktop Filer does since RISC OS 3.0 – it does its own thing. Before that, it just did *Copy.

Yes, confusing coming from VMS!

I have no idea what the desktop Filer does since RISC OS 3.0 – it does its own thing. Before that, it just did *Copy.

That will identify where the discrepancy crept in then – when the desktop copy became a background operation.

when the desktop copy became a background operation

Indeed – I was surprised when it was decoupled that way. My preference had been for *Copy /*Wipe (via the underlying OS_FSControl) to be extended with a desktop mode so clients could more easily benefit from this.

Answered backwards:

Sorry, that doesn’t behave reasonably. They should be consistent.

Agreed, everything should be consistent (including this)

~C don’t request confirmation, no matter what the “Newer” condition decision
~N don’t care whether source file is newer than destination
So, on the basis that the two ~ in the condition set do not negate each other (and would thus require confirmation)

~N~C overwrites files regardless of date

Is correct, don’t care about dates and don’t want a confirm for the action

N~C doesn’t overwrite regardless of date.

Is not correct, it should overwrite (without confirmation) if the source is newer than the destination, or there is no existing destination file.

The answer appears to be that both methods (CI and GUI¹) fail to meet the expected conditions.

From the explanation Stuart gave, it’s broken, and it’s always been broken.
To cap it all the CLI and Obey actions differ, so it’s double broken.

¹ Edited.

the CLI and Obey actions differ, so it’s double broken

You mean the CLI and GUI.

You mean the CLI and GUI.

Yeah, loss of focus. Edit…

What I should also have said is the expansion of that regarding Force, which should only be required to force an overwrite action on a locked file.

As the behaviour at the command line is consistant, and if you dig is documented in some places, I would suggest that the filer operations need reworked to be consistant.

They both need rework as both exhibit incorrect behaviour. Force should not be required except when the destination files are locked.

Thank goodness the desktop copy works correctly. Files are overwritten (unless they are locked) without having to set the ‘F’ flag. Only if they are locked is the ‘F’ flag required. It would be a nightmare if you used the desktop drag method to copy a newer version of an application over a previously saved copy and it just didn’t copy anything and had no way of telling you!

I assume that the command line copy behaves differently because it ‘knows you are looking’. The documentation says it uses the copy$options system variable but it doesn’t. If you set all the ‘Options’ flags to unset (on the desktop) and then look at the copy$options variable it has not been updated and still has both C and V set and so the desktop options are clearly kept in a separate place with copy$options only specifying the immediate post boot state for the desktop ooptions.

I had not realised the command line copy was so different.

The only question now is does the copy command work differently depending whether it is being called from within the desktop (i.e. from an Obey file or a Taskwindow) or from the CLI?

Where is the CMOS setting for the FilerAction (desktop drag and drop copy) default copy options stored then? I can’t see it as a *status item so it must be copy$options then. I use Filer/Options to set Verbose and Force as my default but I am not sure where the OS stores them. I have always assumed that the default *copy options were the same thing, but it appears not.

Where is the CMOS setting for the FilerAction

Boot=>Choices→Boot→Tasks, obey file called FlrSetup

which contains Filer_options followed by some of the copy options, set in configure, filer, in my case -Verbose -Newer -Faster.

That needs careful reading, because I’ve set all 3 of those to ON
So -Newer is the same as N, its absence means ~N, i.e. inverted.

Ah! In my case it is in:

HostFS::HardDisc4.$.!Boot.Choices.Users.Single.Boot.Tasks.FlrSetup

X Filer_Options  -Verbose -Force -TransientSelections

but there doesn’t seem anywhere to store the default options for the command line copy.

Sometimes when I download a distro I finbd that someone has accidentally set the ‘Newer’ option which is not a wise thing to do. For example if you are copying a new !Boot structure to update your system, any problem with datestamps will leave you with very strange errors.

After a clean restart of one of my rPis I get:

show copy
Copy$Options : A C ~D ~F ~L ~N ~P ~Q ~R ~S ~T V
*help copy
==> Help on keyword Copy
*Copy copies one or more objects that match the given wildcarded specification between directories. Options are taken from the
system variable Copy$Options and those given to the command.
Options: (use ~ to force off,eg. ~C)
A(ccess) Force destination access to same as source {on}
C(onfirm) Prompt for confirmation of each copy {on}
D(elete) Delete the source object after copy {off}
F(orce) Force overwriting of existing objects {off}
L(ook) Look at destination before loading source file {off}
N(ewer) Copy only if source is more recent than destination {off}
P(rompt) Prompt for the disc to be changed as needed in copy {off}
Q(uick) Use application workspace to speed file transfer {off}
R(ecurse) Copy subdirectories and contents {off}
S(tamp) Restamp datestamped files after copying {off}
sT(ructure) Copy only the directory structure {off}
V(erbose) Print information on each object copied {on}
Syntax: *Copy []

I’m certain I don’t do anything in my boot system to change it, so that would seem to be the system default.

If I wanted to be absolutely certain what copy$options was set to, I’d set it in an obey file and add that to “run at startup”.

It looks as though Filer_Action (which is what handles drag-copy in the background) has fixed values for a lot of those, as for example it creates directory trees, whereas command-line copy with default options doesn’t. It has an additional option “faster” which reduces what Verbose outputs.

So it’s not just that changes the meanings of some switches, but it has different ones too.

Incidentally if you change the Verbose option to Off while a Filer_Action copy is going (using menu off the display) the display goes away and can’t be got back. I think it restores the setting at a restart.

Ah! In my case it is in:

An obvious Select/Adjust boot structure. Not sure whether that’s significant.

Are there regression tests for all these copy options and combinations there of?

Looking at Alan’s post above and PRM 2-152 it seems the command line copy documentation is clear and correct (and consistent with what actually happens). The options are described in detail. Objects are not copied if there is a destination file of the same name, whether locked or not, unless you specify F. Also that N prevents the copying of older files. I had not realised this before, but when using the command line copy had always got the confirm option ticked anyway.

It is the filer action (drag and drop) copy that is a bit terse. It just refers (PRM 3-236) to the options as Verbose, Confirm, Force and Newer (as opposed to copying always) without any further explanation about their detailed meaning or any mention that in a desktop environment existing objects will be overwritten unless they are locked as that makes more sense.

The options are described in detail. Objects are not copied if there is a destination file of the same name, whether locked or not, unless you specify F.

Which is essentially, root and branch wrong.

F is to force over writing irrespective of lock status, it isn’t a crutch for an incorrectly implemented N

Which is essentially, root and branch wrong.

It does seem a strange decision to block overwriting an identically named object during a command line copy but it seems to have been that way for some time. Thank goodness the filer action implementation took a more sensible route.

Don’t blame N though – that was correctly described and works correctly – it prevents copying of older files that would, otherwise, have been copied. It works correctly and independently.

Don’t blame N though – that was correctly described and works correctly – it prevents copying of older files that would, otherwise, have been copied. It works correctly and independently.

The operation of N is wrong in the circumstances described.
N should always allow the over writing of an unlocked file with a newer file.
F should only be required to override the lock on a locked file.

I always believed Force was assoicated with locked files … but I can find no trace of that, just that it has to be used to overwrite existing files. Where are Locked files mentioned?

I always believed Force was assoicated with locked files … but I can find no trace of that, just that it has to be used to overwrite existing files.

See PRM.

F(orce) Force overwriting of existing objects.
Default OFF.
Performs the copy, regardless of whether the destination files exist, or what their access rights are. The files can be overwritten even if they are locked or have no write permission.

@David: Agreed! I admit my understanding had been wrong. I was really challenging Steve P to say where he got his understanding that F has any association with Locking.

I really hope that this thread will result in a generally agreed document somewhere which will (tautology warning) definitively define the various behaviours!