[<<]Message[>>] [<<]Author[>>] [<<]Subject[>>] [<<]Thread[>>]
Number : 510 Date : 2001-08-03 Author : Dan Anderson Subject : Re: maybe stupid question but...... Size(KB) : 8
I recognize that this is not an xxcopy-specific approach, but can the creation date of specific files be altered by changing the date on the computer, then re-saving the file, and changing the computer date back again? My recollection is that there are hazards with doing this sort of thing but I don't recall what they would be. ...Dan ============================= ----- Original Message ----- From: Kan Yabumoto To: Sent: Thursday, August 02, 2001 10:46 PM Subject: Re: [xxcopy] maybe stupid question but...... > > 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. > > > > > > > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ > >
This message if part of XXCOPY's message Archive. The archive contains all the messages posted at Yahoo!Groups: XXCOPY.