[<<]Message[>>] [<<]Author[>>] [<<]Subject [<<]Thread
Number : 3228 Date : 2002-12-11 Author : Kan Yabumoto Subject : Re: v. 2.83.3 and CLONE Size(KB) : 6
Mike: Well, the handling of the timestamps are really complicated issue. The core of the question is to what degree XXCOPY should duplicate what are in the source to the respective components in the destination. In some sense, /CLONE should do as much faithful duplication as it should. But, that all depends upon what we want CLONE to mean. That is, on the one hand, it is desirable to do as complete duplication as you can get. On the other hand, the Creation and LastAccess timestamps have their own purposes which also need to be honored as well. So, the current XXCOPY behavior is not really an accident but pretty much as we intended. And, what XXCOPY should do with the /CLONE/TC as opposed to the bare /CLONE itself. If you really observe the /CLONE/TC in a freshly created destination directory, you will find the result exactly what you wanted. The sticky question is should XXOCPY faithfully duplicate everything (retro-patch *ALL* the files's LastAccess dates and also those of the subdirectories)? If you really analyze the spirit of what the incremental backup that a /CLONE operation on an existing destinations does, the answer is harder to make. For one thing, the incremental backup, by its very nature, tries to skip all files that are the same (by the file size and the LastWrite value). Being consistent to this logic, we chose not to alter the existing directory timestamps (Creation, LastWrite and LastAccess) --- whether or not the /TC switch is present. The other thing is that when you force a /CLONE/TC operation to retro-fit *ALL* timestamps (mostly, the LastAccess value is the one which is relevant here for files), XXCOPY will have to retouch basically *ALL* files and readjust all of the timestamp values (especially the LastAccess values). From our point of view, to check if *ALL* the three timestamps are the same and if any of them are different from their counterparts in the source, then, to readjust the timestamps, then, it is not as efficient as doing *ALL* timestamps updates without even checking them in the first place ---- the unconditional timestamp refreshing operation will be many times faster. This somewhat contradicts the spirit of /BI --- to skip files that are "the same". Similarly, should XXCOPY really change *ALL* existing directory timestamps when /CLONE/TC is specified? I don't know the real answer to these questions as to what's best. I will give a little more thoughts on this question. Currently, /CLONE/TC will skip files whose size and LastWrite values are the same as those in the source. For a similar reason, /CLONE/TC does not bother the existing directory timestamps. In other words, if we were to reajust *ALL* timestamps of the directories, then, naturally, *ALL* timestammps of the files need to be refreshed. That is hardly an incremantal backup anymore. We are willing to make a variation of /CLONE which will do an "unconditional duplication of everything. If this is the case, it probably would be better to go all the way and refresh all the file-contents as well ---- again, this is in a similar logic as to verify all the file contents in a byte-by-byte fashion and only when a discrepancy is detected, then, the file will be re-written --- this is obviously inferior to unconditionally copy all the file contents. If you do this, then, we come to a full circle and it is more efficient to start a new destination by /CLONE/TC as a new directory. Finally, let me point out that we have been working on a new switch, /TF (still undocumented and we plan to change the way it operates). /TF is to "fixup" timestamps just like how /SF (fixup security info) works. That is, we find it is useful to have a feature which will adjust the timestamps without copying the file contents. When we use the /TF switch (when it officially debuts, that is), you will have the means to quickly set the time values exactly what you want. When that happens, we also intend to patch the directory timestamps as well. (Don't try the /TF switch in an important directory --- play with it if you are curious on a temporary directory only) When we envisioned and started to implement the /TC (and /TF --- plus another variation, /TT --- touch the source file ---- at this moment, it is meant to adjust the LastAccess value but could also modify the other two), we were thinking of making each of these switches operation only one aspect of timestamps operations. At least, having them do their own little thing and let them be combined in anyway the user wants is more flexible than having /CLONE and its variation perform a "canned" combination. But, during the past few weeks, when we were working on these features and how they fit one another, I started to feel very much as you were thinking. That is, whether /CLONE/TC should always readjust all the three timestamps unconditionally. The answer may be yes. Again, let me chew these idea a little more. I welcome suggestions in these delicate issues. Kan Yabumoto =================================================== At 2002-12-10 06:06, you wrote: >Kan - > >I downloaded the latest release and tried it out regarding the NTFS >folder stamps. It is much better preserving the stamps in going from >FAT32 to NTFS, however there seems to still be a slight problem. If >a folder from the source doesn't exist on the NTFS destination, then >the stamps are replicated on the destination folder just fine. But, >if the folder already exists on the destination and there are updates >within the folder, the LastWrite date on the destination folder is >made current regardless of the LastWrite date on the source folder. >To test this, I did the following (C: is FAT32 and G: is NTFS) ... > >"G:\Downloads" does not exist initially. > >XXCOPY "C:\Downloads" "G:\Downloads" /CLONE/TC > >XXCOPY "G:\Downloads" /S/LH/LTREE >Shows all stamps preserved. > >Create a dummy text file inside one of the subfolders >in "C:\Downloads" with the subfolder itself having an old LastWrite >date. > >XXCOPY "C:\Downloads" /S/LH/LTREE >Shows the stamps on the subfolder as unchanged. > >XXCOPY "C:\Downloads" "G:\Downloads" /CLONE/TC >The only file copied over is the dummy text file. > >XXCOPY "G:\Downloads" /S/LH/LTREE >Shows the LastWrite date on the subfolder is current even though the >LastWrite date on the source subfolder is still the old date. > >Mike
This message if part of XXCOPY's message Archive. The archive contains all the messages posted at Yahoo!Groups: XXCOPY.