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

Number   :  3208
Date     :  2002-12-06
Author   :  wylykyotee
Subject  :  Re: the elusive timestamp value of the NTFS directory
Size(KB) :  4


Kan -

The LastWrite and LastAccess timestamps on NTFS do seem a bit 
complicated. I normally use Windows Explorer for looking at 
folder/file info. Regarding at the LastAccess date on NTFS, it seems 
to act differently between folders and files. If you open up a 
folder that has both subfolders and files, the LastAccess date on all 
the subfolders will be changed to the current date (even without 
opening the subfolders). However, the LastAccess date on the files 
will stay unchanged. Like you said, this could be a short-coming of 
WE. You are right in that it has a quantum-like feel in that the act 
of observing changes the thing being observed ... at least as far as 
NTFS folders go. Of course, if you are observing something regarding 
the last observation of that thing, then that observing would itself 
be the last observation. Maybe some Zen-like logic to look without 
looking would be in order here.

To tell you the truth, I don't usually display or use the LastAccess 
date much. I'm normally just concerned with the Create and LastWrite 
dates. So, if the LastWrite date issue could be resolved in cloning 
for NTFS folders, that would be great. And thanks again for your 
responses on all this.

Mike


--- In xxcopy@y..., Kan Yabumoto  wrote:
> 
> 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.