Hi roMancer
I originally did wonder about that, but it leads to all sorts of special cases that need to be checked for- going from one hour to the other, from one day to the next at midnight, etc. So it was going to get messy, but then Neil fixed the issue with the FAT handler. Odd though, as he mentions above that the one in the most recent builds is working, that it seems to have resurfaced. Is it worth trying the process with some other FAT formatted drives to see if the same error occurs?

Cheers,
Nigel.

I don't think there is a regression in fat-handler. The Icaros Xmas preview uses fat-handler 41.63 (22/10/2016) and when I copied a file with an odd number of seconds to a FAT volume (using "Copy CLONE"), the new file had a date one second <b>after</b> the original date. I repeated the test with an ABIv1 nightly from a few days ago with the same result.

Quote:

hey, something just crossed my mind:
how about you add an option to BackupCopy that gives it a tolerance of two seconds? in other words: if target file is up to two seconds older, it's still considered up-to-date.
this...
a) ...would be a workaround for the current fat-handler-bug
and
b) ...might come in handy in similar situations: I remember some issue with some samba-server or something (timestamp, time-server, ...?), and I remember a (very useful) windows-program called "FSync" (I think) that offered this 2-seconds-tolerance-option to explicitly work around the aforementioned issue.

just a suggestion.

is this a known bug? could someone file a bugreport?

Ouch - this means the bug is still hanging around. By the way, a simple solution is to format the USB to SFS - this always sets the datestamp correctly.

Cheers,
Nigel.

I'm using AROS nightly of 2016-11-21.

As i remember it was a bug in the FAT handler. As I said, hopefully one that has not come back in the new release.

Cheers,
Nigel.

interesting, you're right!
"copy" sets correct times (current date/time), but "copy CLONE" occasionally sets time to one second before original file's time - 4 out of 14 files in my testing directory. running "BackupCopy" on source and destination directories copies these four files, as expected.

(no error message or program crash this time. maybe due to low number of files?)

as you said Neil may have worked on this - do you happen to know if this is a "copy" bug, or "vfat.handler" bug, or...?
(if it's a "copy"-bug we have a nice thread for it)

Ho roMancer
Re. BackupCopy problem... I don't think it's worth starting a whole new thread for it, so maybe try to get to the bottom of it here?

The problem you describe sounds like one I had a while back with copying to FAT formatted disks. Could you please check the file date on a file copied to the USB? You may find that it is apparently second older than the original, and so when running again you always get the copy occuring. This I think then causes a recursion which ends up with the 'out of memory' error (which itself is something to do with the internal workings of the Hollywood routines used, as that what it's coded in).

The odd thing is I reported this bug a couple of years ago and Neil fixed it. I just tried it with a FAT formatted USB disk on my system and it worked fine, but... I'm still running the previous version of Icaros (I just haven't had time to do any updates since the new one came out at Christmas). You're running the latest version, aren't you? Hopefully it's not a regression.

Cheers,
Nigel.

hi,

maybe create a new forum "Software support / User feedback" where authors can create a thread for their software product?

for the author to make announcements, and for users to leave feedback.

regards,
Ro