[<<]Message[>>] [<<]Author[>>] [<<]Subject[>>] [<<]Thread[>>]
Number : 509 Date : 2001-08-03 Author : Kan Yabumoto Subject : Re: maybe stupid question but...... Size(KB) : 7
The short answer is no. There is no command within XXCOPY which can set the creation date of a file whether a newly created file in a directory for the first time, while the file is being overwritten, or simply to change the creation time of an existing file, there is no mechanism for XXCOPY to set the creation time of a file. ================================ Here's a longer answer. This is a sticky issue with XXCOPY. Up to now, we have not added any command which manipulate the file-creation time of a file. This was somewhat conscious decision even though it is quite easy to do so programming-wise. The reason for this principle is that when you observe how the designers of Microsoft's file systems (FAT/NTFS) treat the file-creation time by examining when and how the file-creation times are handled by Microsoft's programs, it is quite obvious that the file-creation timestamp is to show the time the file was created at the current directory. By seeing no Microsoft's programs manipulate this (and if no other tools including XXCOPY) ever manipulate this sacred value), then, we can tell when a file was created in the directory no matter what. Once we break the rules (of course, Microsoft usually add features like the file-creation time and never really officially documents the motivation for the feature and how it must be administered by all rule-abiding utilities), the intent of the feature will be ruined and we will no longer tell anything from the file-creation time. --------------------------------------------------------- In the case of the third timestamp which is attached to every file --- the last-access time is a sad story in my opinion. I'm pretty sure the original intent of this value by the designer of this feature was that by having a timestamp which can tell when a particular file was utilized for it's "intended purposes", then, you can tell which file are "dormant" (not "in use" for some period of time) by looking at the last-access time. In order for this timestamp value to mean anything, the last-use of the file must be recorded. In the case of Microsoft Word's document file, when a .DOC file is opened by Word (or equivalent DOC-browser tools), the last-use timestamp should be updated. If the file-accessing program(s) are made responsible, and the participating programs diligently (without exception) set the last-use time to the time the file is opened, the value will have really useful function. The backup administrator could then utilize the last- access timestamp to determine dormant files and move them to an archive area (either off-line, near-line or to backup-storage such as tape) and purge them from the primary storage area. However, Microsoft's designers apparently thought it was too much to ask all programmers of utilities to update the timestamp. Instead, the designers decided the last-access value be updated by the file-system (the kernel program which takes the responsibility of the bookkeeping of files) automatically. In reality, every time a file is opened (for read, write or both), the last- access timestamp will be updated. What they should have done was to exclude certain file-management accesses from this. That is, they should have implemented and enforced a simple rule that the last-access timestamp to reflect the last "real use" but not a backup and routine file copy occasion being considered as a real use. The truth is that no such consideration was made and a backup operation by COPY (XCOPY or drag-and-drop method) ends up updating the last-access timestamp. Therefore, if you perform any system backup, the last-access timestamp becomes totally useless. Any file-read operation (including access for backup) will update the last-access. Therefore, you can't tell which files are dormant. It was a potentially useful feature of a file system. Now it is just an overhead in file-access and file- management activities with no appreciable benefit. --------------------------------------------------------- So, when XXCOPY becomes a rule-breaker and manipulates the file-creation time, the integrity of the file-creation time (whatever the original and current purpose of the value may be) will be questionable. I am not aware of any file-management tool which modifies the value. In a sense, it is a good thing. The archive bit of a file is in somewhat similar situation. If you take full responsibility and administer the /M switch (using XCOPY and/or XXCOPY), you can say the archive bit is useful to identify which files to be archived in a periodic backup regime. Since we do not believe the archive bit can be trusted, we do not recommend the use of the bit (and therefore the use of /M switch). We suggest the use of /BI which uses the last-write timestamp and file size info to determine whether a file needs a backup or not. In a sense, the archive bit follows the similar fate of the last-access timestamp (not to be trusted for the intended purposes). ----------------- If anyone gets confused by my point, let me rephrase my opinion in a more direct way. Jack stated "I need to copy files while keeping the file's creation date in tact." In a way, what Jack is saying is that he wants the file system to modify its behavior which we have known to behave in certain ways for some purpose he has in mind. My instinct says it is a bad thing to do even though he can see some benefit (and I could easily agree on him for a narrow scope of his purpose). But, if I view the bigger picture, I'm not sure if that's a good thing to do. --------------------------------------------------------- Let me cite one more sad episode in storage system. As soon as some diskette manufacturers started to sell pre-formatted diskette (for user-convenience), the volume serial number became useless for identifying the diskette because all such manufacturers made a simple sector-to-sector, byte-by-byte copying in violation of the spirit of the volume serial number (which was encoded in four bytes in the first sector). When you use the DISKCOPY DOS command, the program did it right by always assigning a unique serial number even when it was copying the whole diskette. All of this was made moot by the ignorant (or lazy) diskette manufacturers who duplicated every byte on the media. -------------------------------------------------------- But, of course, if it is Jack's system and not mine, who am I to say what is right and what is not for him? So, on the one hand, I have a reservation to go along with Jack, I can see some benefit of a clean backup which duplicates everything. In other words, I'm not 100% against the idea. (If any of Microsoft's utilities has this feature, I would have no reservation on this at all --- but to be the first and the only one, I will have to take all the blame from the industry...) ----------------------------------------------------------- Having said all this, we could add the suggested function (to manipulate the creation time of a file) --- along with a disclaimer and strong recommendation against the use of the feature)... Any comment on this issue by anyone? Kan Yabumoto =============================================================== At 2001-08-01 13:26, Jack Kitchen wrote: >I need to copy files while keeping the file's creation date in tact. >I've tried the "K" switches, but they did not seem to work. I am >running NT4. thanks for your help.
This message if part of XXCOPY's message Archive. The archive contains all the messages posted at Yahoo!Groups: XXCOPY.