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
Re: cp -u vs. vfat's TWO seconds
jidanni.org> writes: > 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? FAT is not a POSIX-compliant file system. POSIX requires file systems to have a granularity of 1 second or less. If anything, the conspiricy to wear out USB memory sticks faster is due to a rather poor industry decision to use such a stupid file system as the default. That said, a lot of the problem is that most existing OS's don't provide easy access to what the underlying granularity of the current file system is. The next version of POSIX is adding fpathconf(n,_PC_TIMESTAMP_RESOLUTION) to solve this problem, but it is not widely implemented yet. If excess wear on your non- compliant file system really bothers you that much, then consider submitting a patch that provides a replacement fpathconf for systems that don't yet implement _PC_TIMESTAMP_RESOLUTION, and which then teaches cp to use fpathconf to get the truncation right even with your 2-second resolution file system. -- Eric Blake ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
