[<<]Message[>>]        Author[>>]    [<<]Subject[>>]    [<<]Thread[>>]

Number   :  19
Date     :  2001-05-13
Author   :  Dan Anderson
Subject  :  Re: XXCOPY in a Netware Mapped drive
Size(KB) :  2


Hi Kan,

I may be missing some basics by jumping into the middle of a discussion, but
could the timestamp difference created when copying files between different
file systems be resolved by means of a tolerance option parameter under
xxcopy? For example, if the file sizes are the same, one could specify an
option that would treat the files as identical if the time difference is
less than, say, 3 seconds.

Regards,
Dan

==================================

----- Original Message -----
From: Kan Yabumoto XXCOPY tech 
To: Yahoo XXCOPY group 
Sent: Sunday, May 13, 2001 1:17 AM
Subject: Re: [xxcopy] Re: XXCOPY in a Netware Mapped drive


>
> Max,
>
> It's not XXCOPY, XCOPY or COPY which handles the timestamp. The
> file system (the software component which is responsible for the NTFS,
> FAT (I did not distinguish FAT12, FAT16, or FAT32 because they
> all behave the same way with regard to the timestamp).
>
> Let me repeat what I said. When you copy a file which was created
> on a NTFS volume into a FAT volume using any of the file-copy tools,
> the file time will be changed unless the file time happens to be
> already aligned to the exact two-second granularity. When you
> compare the file time (I don't care which tool you use to compare the
> file time) between the one in the NTFS and the one in the FAT volume,
> you will see the difference. Since XXCOPY's incremental backup scheme
> (the /CLONE or /BI switch) considers the two are different when either
> the file size or file time is different, the file will undergo
> backup (uncecessary) copy. If you use the archive-bit based incremental
> backup (using the /M switch), then the operation does not look at
> the timestamp (but rather, the archive bit), the file would be
> skipped even if the two file times between the source and the backup
> directories are slightly different due to the timestamp truncation
> which took place in the first backup operation.
>
> In other words, the difference in time value precision (granularity)
> maintained by the various file systems cause the timestamp
> value to change when a file is copied from the higher-precision
> file system (NTFS) to the less-precision (FAT) file system. This
> is nothing to do with XXCOPY.
>
> Kan Yabumoto
> 
>
> =======================================================================
> At 2001-05-13 00:40, max08122000@y... wrote:
>
> >What I don't understand is that why the simple NT's xcopy or copy
> >works or preserves the date and time in this case.?
> >
> >I'll get a FAT volume up in the w2k svr (how about FAT32?) to give it
> >another try and also the v2557 version. Cheers.
> >
> >Regards,
> >MAX
>
>
> To unsubscribe from this group, send an email to:
> xxcopy-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>



This message if part of XXCOPY's message Archive.
The archive contains all the messages posted at Yahoo!Groups: XXCOPY.