Copy Command

In a project I was working on a couple of years ago I needed to update some files with their newer versions by running an obey file with the copy options set to ~C N R. I discovered that while files were copied if they did not exist in the destination, existing files were not updated with the newer versions as expected.

Both the PRM and *Help state:
N(ewer) Copy only if source is more recent than destination.

Testing on various versions of RO from v4.02 up to 5.29 confirmed this failure to copy newer files over older ones in the destination (which were not locked).

I was propmpted to try adding the F(orce) switch to the copy options ( ~C F N R ) which resulted in overwriting of the files in the destination with their newer versions. More recent testing has confirmed that F when modified by N only copies the newer files and when used alone copies everything as expected.

Clearly there is a mismatch between what the PRM and the *Help state as the action of the N switch, and what actually happens. As this situation has existed for at least 20+ years to maintain backward compatibility it is probably easier to update the PRM and *Help to state that the N switch acts as a Modifier to the F switch. For example:

N(ewer) Modifies F to Copy only if source is more recent than destination

It should be noted that copying with the GUI filer Options set to Newer work as expected and are not affected by this mismatch which seems to be confined to the command line Copy.

A detailed description and my test files can be found here
Richard Darby.

*Copy and the underlying OS_FSControl has indeed always been this way by design.

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]

I don’t see that there’s a problem. Force means “ignore the file protection settings on the destination”. It does not mean “copy at all costs”.

Newer means don’t overwrite newer with older.

There is a bit of an issue on foreign filing systems, such as HostFS, where the datestamp exposed to RISC OS is one of many possible candidates – originally created, last updated etc. It is frustrating that editing a file on HostFS sometimes updates just the ‘last accessed’ or whatever date, leaving the datestamp seen by RISC OS as wrong – the original creation date for example. The option ‘Newer’ does not work on such filing systems.

The point is, that if you use the N switch on its own it does not overwrite older files with the newer version unless the F switch is also included, which is not what the PRM or *Help says.

Are you sure? The F and N switches should operate independently as they do not overlap at all.

The F and N switches should operate independently as they do not overlap at all.

The truth would appear to be buried in the small print – Force says:

F(orce)         Force overwriting of existing objects {off}

It’s the “existing” there.

That said, this came as a surprise to me too. I always figured F(orce) was to specify that a file should be copied regardless of what’s already there including if the file is locked. ¹

Really, it should not require Force to be specified with Newer. After all, isn’t it pretty bloody implicit in the words “Copy only if source is more recent than destination” that you are intending to copy a file on top of an existing copy if it is newer?

To conflate these two different operations seems wrong to me.

¹ Just tested, and yes, ~CF will happily overwrite a locked file.

I think confusion stems from it not stating anywhere that in the case of ~C being in force, *Copy won’t atttempt to copy overwriting existing objects unless F is also specified. It’s only then that it bothers to work out wther the source is newer than destination if N is specified.

Hard to express everything in the *Help response – oh to have had the space to have man pages or their like to describe commands. IMO *Copy actually used to be documented better in the RISC OS 2 User Guide than in the current PRMs.

Are you sure? The F and N switches should operate independently as they do not overlap at all.

That is what I thought originally and spent days trying to get Copy to overwrite older files with newer until I was tipped off to include the F switch.

I think confusion stems from it not stating anywhere that in the case of ~C being in force, *Copy won’t atttempt to copy overwriting existing objects unless F is also specified. It’s only then that it bothers to work out wther the source is newer than destination if N is specified.

When running a script who would want to have the C switch in operation, it would mean having to confirm each copy. when running in a script ~C would normally be what is required.

It’s the “existing” there.

And there’s me thinking the operative word was Force. i.e. I don’t care if it’s read only I’m still copying from source to destination.

Newer is logically "copy in if it doesn’t exist OR if it does, but the source item is newer than the existing.
No one said anything about ONLY copying files that already exist.

Anyway, Stuart has admitted it’s his fault :)

trying to get Copy to overwrite older files with newer

That cannot work. The ‘newer’ option is a preventitive not an enabler. It will not do anything other than prevent the copying of older files. It would be better described as ‘prevent copying of an older file onto a newer file when set’.

On some distros it was set by default and caused mayhem as dragging files to update things failed if the datestamps were wrong.

Thanks Chris, that would be better wording, suitably terse for its help.

As for faults, Steve, I like them so much I did a geology degree!

The ‘newer’ option is a preventitive not an enabler. It will not do anything other than prevent the copying of older files.

I’m not quite sure what to say here. Both the PRM and *Help state the folowing.

N(ewer) Copy only if source is more recent than destination

I interpret that as meaning only copy if the file is more recent than the file it is to replace. Using the N switch without the F switch fails to do that. I have done numerous tests to prove that. I have just done a test without the N switch (which is off by default) and with switches ~C R V active, copy fails to replace older files with newer versions which is what I would expect.

On some distros it was set by default and caused mayhem as dragging files to update things failed if the datestamps were wrong.

While this may be true, we are not talking about the Opions set in the GUI filer where setting Newer updates older files with newer ones, this discussion is about running the Copy command in an Obey script.

My test files can be downloaded from here You are free to try them out.

This Richard agrees with that Richard. N should copy if newer, exactly as it says it would. The presence or absence of F should only matter if some of the existing files are locked.

Anything else is illogical.

My take on this is to suggesst that it’s the influence of the C option that is significant. The overwriting behaviour is different with C and with ~C because of the need (or not) for user interaction. Perhaps *Copy, being originally desinged for CLI use, never had its options fully examined for Obey file use?

Have you tried using the C option with a command-line copy. It puts a tiny indicator on screen, which is almost invisibly small on a modern-sized monitor, and too small to click on. I suppose it might respond to the Y and N keys, or maybe Ret and Esc.

Yes, when testing *Copy in a Task Window, there’s an icon of a mouse with three buttons, Select having a Y for Yes below it. Pressing Select then saves you having to type Y in the Task Window.

there’s an icon of a mouse with three buttons

and on my 2560×1440 monitor, it’s approx 2mm across. Each of the button images is too small to click on accurately.

It puts a tiny indicator on screen

Er, that’s the cursor. Just click. See OS_Confirm

O Gosh, I only started this to report that when using Copy silently in an Obey script the N switch didn’t do what the PRM and *Help said it should, and the only way to get it to copy newer files was to combine it with the F switch.

This has been working for me over the past 2 years.

I interpret that as meaning only copy if the file is more recent than the file it is to replace.

Correct interpretation.

The complication is if the destination is locked. The N flag is preventitive rather than permissive. To copy over locked objects requires the F flag.

Another complication with the R flag set is that both the directory and the files within it have datestamps. Quite often the destination directory will be newer than the source even if its contents are not. Not sure what happens then. It gets even more complicated with application directories, which present the datestamp of a !RunImage file found within.

Another complication is with foreign filing systems – Windows (HostFS) has several dates such as creation date, last accessed date, last modified date. Sometimes an edit will update the creation date sometimes not, same with copying a newer file. Only one of these dates is presented to RISC OS as the datestamp and this can be quite confusing.

This discussion has been going on here, and in another thread and on a mailing list.

The upshot seems to be that there is an undocumented feature of the F option. If copy is done in a command line with ~C and N then there’s no way for copy to ask before overwriting newer files. F seems to have been extended to mean “override the need to confirm”.

Where the documentation is misleading is that it doesn’t mention that Newer requires a confirm.

Where the documentation is misleading is that it doesn’t mention that Newer requires a confirm.

It should mention that ‘Newer’ does not require ‘Confirm’ unless you want to copy over locked objects in which case you need either C or F.

@Chris: It’s not a locked objects thing.

If copy is done in a command line with ~C then there’s no way for copy to ask before overwriting existing files, so it doesn’t, unless F is specified.

It’s confusing because it is inconsistent. ~C means “don’t ask, just do it”. EXCEPT in the case of Newer, when it means “don’t ask, just don’t do it”. Force then restores normality to Newer.

Not surprisingly, this confuses people, particularly as it isn’t documented.

I guess not many people have discovered this precise explanation, because when command-line copying I at least always use Force just to avoid errors.

It now occurs to me to ask “What happens if you copy over existing files without Newer and without Confirm?”

Does it always overwrite, or never? To be consistent with the above, it should be never.

Just tried it. It is ALWAYS.

So ~N~C overwrites files regardless of date
N~C doesn’t overwrite regardless of date.

Sorry, that doesn’t behave reasonably.