[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 truncate
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
[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
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
[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
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 futur
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 syste
