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

Number   :  3207
Date     :  2002-12-06
Author   :  Kan Yabumoto
Subject  :  the elusive timestamp value of the NTFS directory
Size(KB) :  3



Mike:

Let me say that the behavior of NTFS directory timestamps
with regard to various file/directory I/O activities is
far more complex than I originally estimated.

In retrospect, that was why I made an embarrassing statement
where I said you can't change the NTFS directory timestamps.
In fact, NTFS allowed XXCOPY to change the directory timestamps
all along. What I did not realize until recently was that
the timestamps that was changed by XXCOPY would undergo
further changes in subsequent directory access.

Right now, assessing the directory itself seems to be
causing some unintended change in the timestamp values:
I was using the following command for observation:

xxcopy \dirname\ /s/lh/ltree

But, even this may change the timestamps. So, back to
square one. We will have to first make XXCOPY display
the current timestamp value without any change to the
values (the last-access values are especially nasty).

----------------------------------------------------
I once ridiculed the behavior of Windows Explorer
when it tries to display the LastAccess value of
file object --- which always shows today's date,
but I'm almost repeating the same mistake with
XXCOPY here. See the article XXTB #15
http://www.xxcopy.com/xxcopy15.htm
----------------------------------------------------

I'm not sure what tool you are using to see the result
of timestamp manipulation. Whatever you use for this,
you have to have a tool that does not alter the value
that you are observing.

Sounds like the quantum mechanics' world...

So, let me just acknowledge that v.2.83.1 still has
problem with directory timestamps. Once I make XXCOPY
to observe the timestamp values without disturbing them,
the fix should be relatively easy...

Kan Yabumoto
============================================================


At 2002-12-06 02:11, you wrote:
>That little chart didn't seem to come out quite right after posting.
>Bottom line though was that the LastWrite and LastAccess dates on
>destination NTFS folders were still not being preserved. Thanks,
>Mike
>
>--- In xxcopy@y..., "wylykyotee"  wrote:
> > Thanks for the quick response Kan. Here are my file date results
> > using 2.83.1 and /CLONE/TC.
> >
> > -----Dest File System------
> > File Date FAT32 NTFS
> > ----------- ------------- -------------
> > Folders Create Preserved Preserved
> > LastWrite Preserved NOT Preserved
> > LastAccess Preserved NOT Preserved
> >
> > Files Create Preserved Preserved
> > LastWrite Preserved Preserved
> > LastAccess Preserved Preserved
> >
> >
> > Looks like everything is okay now except for the NTFS folders.
>Just
> > speculation, but I wonder if XXCOPY is updating a folder's dates
> > before it is done doing stuff inside the folder. I believe with
> > FAT32, you can copy a file into a folder and it doesn't touch any
>of
> > the dates on the folder itself. However, with NTFS, the LastWrite
> > and LastAccess dates of a folder are made current if you copy a
>file
> > into the folder, regardless of the dates on the files themselves.
> >
> > Mike



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