FAT32 time difference

Upfront apology – can’t find the original thread. Did the time difference problem with files saved to FAT32 get resolved? I can’t recall.

I ask because I bought a 16G USB stick to use for backup & such. I left the format as supplied on the assumption that with Fat32FS (1.40) it would be fine. Each time I did a backup using SyncDiscs (1.23), the whole of the previous backup was saved to its scrap directory and then fully replaced rather than just dealing with changes. Assuming it was the old timestamp problem I just reformatted to filecore and that was fine.

[Edit] Now can’t reproduce the problem with test file saves, though I can with SyncDiscs. I’m thinking it’s a SyncDiscs/FAT problem.

There shouldn’t be any difference between filecore and FAT as regards time handling – both use UTC. I use DirSync which has an option to treat files with a one hour difference as the same, and also an option to treat files within 2 seconds as the same (as FAT only stores time to the nearest two seconds – the accurate timestamp position is used to hold the riscos filetype). Hopefully SyncDiscs will provide options for these the same as DirSync.

Jeff

It is the same problem, I mean, in the BUG thread…

I use DirSync which has an option to treat files with a one hour difference as the same, and also an option to treat files within 2 seconds as the same (as FAT only stores time to the nearest two seconds – the accurate timestamp position is used to hold the riscos filetype). Hopefully SyncDiscs will provide options for these the same as DirSync.

SyncDiscs already has this option – although you can set the time difference only up to 90 seconds at the moment. Shouldn’t be a problem to increase that.

I was actually using SyncDiscs last night to backup the ARMini drives to external FAT32 formatted drives and there didn’t seem to be any problem skipping files that hadn’t changed. However, I will have another look at the problem.

@Fred. One minor query – were you using multitasking mode or single tasking?

Aha. This is a problem I solved a long time ago.

In my case it was a question of copying files from a RiscPC to an emulated machine on a Windows host over ShareFS. The problem is one of time granularity. Filecore uses centisecond accuracy, but the NTFS directories accessed via HostFS only use second granularity. Hence 99% of files copied to such a drive get their timestamps changed (and rounded down, crucially).

I fixed it by writing a small module that (in this case) forced all filesystems on the RiscPC to have whole second granularity. It was called WholeSecs. :-) It could just as easily be any other granularity.

Consequently timestamps matched and files don’t get copied unnecessarily.

Hopefully SyncDiscs will provide options for these the same as DirSync.

It does and I have it set to its default, 3 seconds… but just noted that I may not have had the option selected! Have to try when I get the chance.

One minor query – were you using multitasking mode or single tasking?

Multitasking mode.

Back shortly. Well may be longer. The only remaining large stick I have left is an HP PITA that sometimes registers with a kick.

[Edit] That’s that one solved then. Although I had a timestamp variation of 3 seconds set the tick box had obviously eluded me. Tunnel vision. Thanks for prodding me in the right direction.

Glad it is sorted.

That’s that one solved then. Although I had a timestamp variation of 3 seconds set the tick box had obviously eluded me.

Right – maybe I should shade the variation part if the option is not ticked. I have in any case started to increase the range of timestamp ignore difference allowed. There may be a new release soon, since there have been a small number of other changes since v. 1.23 was released.