[<<]Message[>>] [<<]Author[>>] Subject [<<]Thread
Number : 3212 Date : 2002-12-08 Author : Kan Yabumoto Subject : Re: the elusive timestamp value of the NTFS Size(KB) : 5
First of all, under the "normal" circumstance, when we talk about which file is newer (typically for the sake of backing up with the most-commonly used meaning in what's newer), we are all talking in terms of the LastWrite (LastModify) timestamp, not the Creation time (and definitely not LastAccess time). And that is what DIR command typically displays and in nearly all contexts (unless otherwise specified), so-called timestamp and filedate refer to the LastWrite time value. That is true with the DIR command and also true with XXCOPY in its default mode (i.e., without /FC or /FA to explicitly select the other one). At 2002-12-07 01:11, you wrote: >If I understand this issue from the two emails in this thread and >FAAQs #15 and #17, XXCOPY normally compares the LastWrite date, which >is stable and is not changed by XXCOPY in comparing a source with a >destination file in order to determine whether it should be copied. > >Not so? The compare can change the Source LastWrite date? What I was observing in my previous few messages in the "elusive NTFS timestamps" was that XXCOPY has had some difficult time dealing with the NTFS directory timestamps (LastAccess and Creation timestamps and possibly the LastWrite time). These are strictly the problem of the timestamps on NTFS directories and not the timestamps of files (as opposed to directory). >Suppose the Source and Destination files have the same names but >different LastWRite dates. What does /DA do? If the source date is >newer than the destination date doesn't XXCOPY copy the source file >to the destination and date stamp the destination with the source >Last Write date? Yes, of course. When you use /DA, (and most other /Dxx switches as well as /BN, /BO, /BI), XXCOPY uses the LastWrite timestamp as noted above, (that is, unless you modify the default behavior by /FC or /FA which will focus its attention on the Creation or LastAccess, respectively). In the standard file copy, XXCOPY will put the LastWrite timestamp of the source file to the destination's timestamp. The Creation date and LastAccess date for the newly copied file will receive the current time. That's how COPY and XCOPY also behave. Using /TC with XXCOPY, the Creation time and LastAccess time were also copied from those of the source file. >This all is very relevant to me because I am using XXCOPY with file >management software called Xythos. The Xythos client can be used to >map a local drive letter to a remote WebDav folder. Then XXCOPY can >be used to transfer files directly between computers over the >Internet. Also, the Xythos package includes a web interface for >uploading and downloading files using your browser. > >XXCOPY was working pretty well in this application but now I finding >that the file dates reported by DIR on the source and destination >directories do not always agree with what XXCOPY determines in >comparing the dates. Today, a problem was that DIR reported files on >the source (remote) and desitionation (local) directories as being >dated 11/25/02, which is when they were created, while I know that >the source file was last modified on 12/5/02. However, XXCOPY figured >out that the source were newer than the destination files and coppied >them! So DIR _apparently_ reported the file creation dates while >XXCOPY used the File Modified dates. No. DIR command uses the LastWrite date as it should. So, Now, in XP, the DIR command has a switch that allows you to use either LastAccess or Creation timestamp just like XXCOPY. --------------------------------------------------------- XP's DIR command has three timestamp-selection switches /TW LastWrite (same as /FW of XXCOPY) /TA LastAccess (same as /FA of XXCOPY) /TC Creation (same as /FC of XXCOPY) Sounds like Microsoft's programmers are now studying XXCOPY But like anything else, if you don't say anything, a timestamp usually means the LastWrite date. ---------------------------------------------------------- >My question is whether this is a Xythos problem or maybe an XXCOPY >problem. I think it is probably a Xythos problem, because Xythos has >a complicated file versioning scheme built into it that could be the >source of the problem. I do not understand this versioning system >very well yet. So, what you intuitively expect of XXCOPY is what XXCOPY is supposed to do. There is no surprise here. Again, the discussion we had in recent with the timestamp topic was about the funny behavior of XXCOPY where the NTFS directory did not get the proper timestamp values. We are currently working on this to make XXCOPY behave as expected. >So might there be a problem with XXCOPY here or is it more likely a >Xythos problem. > >PS Xythos is a product that XXCOPY should know about >(www.xythos.com). Xythos recently purchased (or something) the >TeamDrive product. Thanks for letting me know about Xythos. I just visited their web site. I will take a closer look at what they offer. Anyway, we have been working on the latest XXCOPY v.2.83.2 which should correct some irregular behaviors of the previous versions. We are uncovering a lot of unexpected behaviors of the WinXP with the NTFS volume which even Microsoft's latest XCOPY has a lot of problems. We are determined to do it exactly right. Just give us a few more days. Kan Yabumoto
This message if part of XXCOPY's message Archive. The archive contains all the messages posted at Yahoo!Groups: XXCOPY.