Filer Copy with Option Newer

Rapsberry Pi, 5.19

Using drag’n’drop copying of directory on SD card to directory on USB memory with Filer→Options→Newer set works OK. But on immediately repeating (which should find no files to copy) Filer action reports lots and takes time to re-copy them. This happens on any number of repeats. The time stamps look the same in the Filer displays, and the problem is most easily demonstrated in areas that are completely static, e.g. in !Fonts.

Using R-Comp’s SafeStore to make the same backups shows no such anomaly.

Is this a known problem, or some incorrect setting in my system?

You do not say what filesystems are involved. If the destination is eg Fat32Fs, then you have to be aware that time stamps may be treated differently to the way filecore adfs might treat them. The same applies if the filesystem is unix based. On some of these ‘foreign’ file systems there is more than one ‘time stamp’, eg time of creation, time of last modification, time of last access. Filecore knows only one time stamp – time last saved – and when copying files it can only assume that the time stamp returned by the file system is the time of last save, even if it is not.

Backup apps such as Safestore or Syncdiscs have to use various extra tests to try to account for such differences.

In my experience, it’s the granularity of a time stamp rather than its type (which will be constant between save sessions). I’ve seen what Bernard described happen when I saved items to a FAT formatted USB device. It’s inevitable with FAT as time stamps are saved in 32 bit words with the last (seconds) bit shifted out: http://stackoverflow.com/questions/15763259/unix-timestamp-to-fat-timestamp

granularity of a time stamp

Yes – I was forgetting that. I did modify SyncDiscs handling of timestamp differences a little to improve its behaviour with Fat devices. This is actually referred to in the SyncDiscs help files.

It’s a shame that Microsoft defined a byte to hold the millisecond part of the timestamp after it had already been used in dosfs to hold part of the filetype. Fat32fs has to be compatible with dosfs in that respect. That’s why some files written by a PC have wacky looking filetypes…

Thanks, gentlemen. The SD card input is of course SDFS and the USB memory is FAT32, and the most probable explanation is a timestamp granularity mismatch. This possibly merits a warning in any description of Filer’s Option Newer for newcomers to RISC OS, though I suppose you could argue that it’s fail-safe: the time stamps wouldn’t ever be out by enough to cause Newer to be ignored.