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

Number   :  4855
Date     :  2003-06-18
Author   :  Garry Deane
Subject  :  Re: XXCOPY16 and Directory Cloning
Size(KB) :  3


--- In xxcopy@yahoogroups.com, Kan Yabumoto  wrote:
> 
> Dale wrote:
>> I've done some more experimenting and no matter what I do,
>> I cannot get the directories to retain their original
>> creation timestamps after I copy files into them.
>> I did not try Win98 as Kan mentioned that it would not
>> likely work.
> 
> I believe the problem is at the "destination base
> directory" rather than the subdirectories underneath.
> 
> If so, it is the design feature rather than a bug.
> When we first designed XXCOPY, we had a choice and
> we made the decision that the "top-most" destination
> directory is considered as a newly created directory
> in the destination volume rather than something
> we copy from somewhere else. The logic is simply this:
> 


Kan, I don't think Dale's problem is with the destination
base directory (although that issue does exist). I think
it relates to the DOS based network server and/or the
underlying operating system and possibly how xxcopy deals
with the date information (not) supplied by the network system.

I did some testing using a boot disk with Win98 DOS
(ver 4.10.2222) and Microsoft's Network Client 3.0 with
the server support add on (see 
http://www.wown.com/j_helmig/dosclien.htm ).

I shared a FAT16 drive on the DOS machine and from NT4,
mapped this share as N:\. I copied the directory structure
to an NTFS drive F:\ using the following:

xxcopy n:\ f:\test\ /t/tcc

This resulted in the directory structure being created and

Create Date = current date
Modified Date = source date

Xxcopy failed to set the create date to the source date and since the 
modified date on an NTFS drive will be updated whenever the contents 
change (i.e. files are added), the modified date won't "stick". 
Therefore neither the Create nor Modified dates are useful to Dale.

I then repeated this with a FAT16 destination drive (on NT4). This 
resulted in the directory structure being created and as above

Create Date = current date
Modified Date = source date

However, since the modified date on a FAT16 drive will not be updated 
when the contents change, this date does "stick". It is also seen in 
explorer using the modified date so even though xxcopy didn't set the 
create date, the modified date matches the source date so this is 
what Dale wants when he views the contents.

I then repeated this with a Win98 FAT16 drive mapped as the source 
and the NTFS drive as the destination. This resulted in the directory 
structure being created and

Create Date = source date
Modified Date = source date

This worked as expected when the source OS was Win98 (also with a 
local NT4 source). Of course the modified date will change as soon as 
files are copied into the tree but the Create date could still be 
retrieved.

So my conclusions are:

With a DOS based source drive, the source date is being retrieved by 
Xxcopy when it sets the modified date but the create date is not 
being supplied and/or is defaulting to the current date. I have no 
idea whether this is related to the OS, network provider or Xxcopy's 
treatment of Create/Modified/Accessed when only one date is available.

If Dale copies the DOS drive to a FAT16 partition, he can get what he 
wants. I don't have any FAT32 partitions so I don't know whether this 
would work as well.

Garry



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