Re: cp -u vs. vfat's TWO seconds
[EMAIL PROTECTED] wrote: Bad news fellows, regarding: `-u' `--update' Do not copy a non-directory that has an existing destination with the same or newer modification time. If time stamps are being preserved, the comparison is to the source time stamp truncated to the resolutions of the destination file system and of the system calls used to update time stamps; this avoids duplicate work if several `cp -pu' commands are executed with the same source and destination. Well it just so happens that the resolution on all(?) vfat flash cards, is TWO seconds, $ w3m -dump http://en.wikipedia.org/wiki/File_Allocation_Table | grep 2\ sec Note that the seconds is recorded only to a 2 second $ cd some/directory/on/my/vfat/flash_card $ stat *|perl -nwe 'm/^Modify:.*(\d\d)\.000/print $1'; echo 04 02 02 02 24 04 04 58 00 24 16 58 58 02 34 --all TWO seconds, (so they are always even numbers above.) This means that set /non-vfat/file /vfat/file $ cp -p $1 $2 #if done during an odd-numbered second of time, $ cp -u $1 $2 #will cause this second line to wastefully fire again. So please investigate your claim that the comparison is to the source time stamp truncated to the resolutions of the destination file system I bet that you never dreamed that you had to consider more than one second vs. fractional second differences. Yes, it's unfortunate that FAT does not allow for higher resolution st_mtime, like it does for creation time. Yet another reason to avoid FAT, whenever possible. It'd be great if you would suggest wording to document this discrepancy. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cp -u vs. vfat's TWO seconds
JM It'd be great if you would suggest wording to document this discrepancy. The wording is fine as is. The problem is that you don't act according to your wording. You think truncate fractional seconds, using one-second buckets to compare, whereas you need to use two-second buckets to compare if detected FAT, I suppose. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cp -u vs. vfat's TWO seconds
[EMAIL PROTECTED] wrote: JM It'd be great if you would suggest wording to document this discrepancy. The wording is fine as is. The problem is that you don't act according to your wording. You think truncate fractional seconds, using one-second buckets to compare, whereas you need to use two-second buckets to compare if detected FAT, I suppose. It's always simple in principle... There are two ways to address the discrepancy: - change code (probably impossible to do non-invasively and efficiently enough to satisfy me). Evidence to the contrary would be welcome, of course. - document a subtle limitation encountered when using a losing file system Guess which one I choose? ;-) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cp -u vs. vfat's TWO seconds
JM - document a subtle limitation encountered when using a losing file system It's the Lingua Franca of USB filesystem where I live. You change your comparison from Modify: 2008-04-03 05:45:22.7 to one second buckets Modify: 2008-04-03 05:45:22 so it should be just as easy to add a two second bucket too The Linux guys went through all the trouble to be able to write the file into the two second bucket, and they you fellows don't follow along: ah ha: GNU/Linux becomes GNU ... / ... Linux: a crack appears. Anyways, all this to encourage you not to make your previous compliancy start to crack due to a moment of convenience. Or whatever. I'm having a vegi-burger. See ya. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cp -u vs. vfat's TWO seconds
[EMAIL PROTECTED] wrote: JM - document a subtle limitation encountered when using a losing file system It's the Lingua Franca of USB filesystem where I live. You change your comparison from Modify: 2008-04-03 05:45:22.7 to one second buckets Modify: 2008-04-03 05:45:22 so it should be just as easy to add a two second bucket too Sorry, but as far as I know, it's not easy at all, in the context of cp. Keep this in perspective: i.e., what's the penalty for not changing the code to match the documentation? The second cp -u invocation in the right two-second interval will do some useless work. Not worth worrying about. The Linux guys went through all the trouble to be able to write the file into the two second bucket, and they you fellows don't follow along: ah ha: GNU/Linux becomes GNU ... / ... Linux: a crack appears. Don't blame Linux ;-) This is due to the FAT specification. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cp -u vs. vfat's TWO seconds
All I know is your program is guilty of conspiracy to wear out people's USB flash cards. If FAT is detected, just run source and destination times thru a chopper like $ m=$(date +%s); echo -n $m--\; expr $m / 2 \* 2 1207175575--1207175574 and cp -u will never blow it again, innocent of any future charges. JM Don't blame Linux ;-) JM This is due to the FAT specification. Different filesystems have different time granularities. Why draw an artificial line above one second just because it is unfamiliar? ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
cp -u vs. vfat's TWO seconds
Bad news fellows, regarding: `-u' `--update' Do not copy a non-directory that has an existing destination with the same or newer modification time. If time stamps are being preserved, the comparison is to the source time stamp truncated to the resolutions of the destination file system and of the system calls used to update time stamps; this avoids duplicate work if several `cp -pu' commands are executed with the same source and destination. Well it just so happens that the resolution on all(?) vfat flash cards, is TWO seconds, $ w3m -dump http://en.wikipedia.org/wiki/File_Allocation_Table | grep 2\ sec Note that the seconds is recorded only to a 2 second $ cd some/directory/on/my/vfat/flash_card $ stat *|perl -nwe 'm/^Modify:.*(\d\d)\.000/print $1'; echo 04 02 02 02 24 04 04 58 00 24 16 58 58 02 34 --all TWO seconds, (so they are always even numbers above.) This means that set /non-vfat/file /vfat/file $ cp -p $1 $2 #if done during an odd-numbered second of time, $ cp -u $1 $2 #will cause this second line to wastefully fire again. So please investigate your claim that the comparison is to the source time stamp truncated to the resolutions of the destination file system I bet that you never dreamed that you had to consider more than one second vs. fractional second differences. cp (GNU coreutils) 6.10 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
