[<<]Message[>>] [<<]Author[>>] [<<]Subject[>>] [<<]Thread
Number : 243 Date : 2001-06-20 Author : Kan Yabumoto Subject : Re: Flatten subdirectories Size(KB) : 6
As I said, the directory-flattening feature is there to do whatever you want. So, this is my take on this issue: If you want to set aside a whole subdirectory into another for an archiving purposes, I see no advantage of making a flat directory for what Jim is doing with his current backup scheme (of naming a subdirectory name using the encoded current date). > xxcopy d:\personal\*.* d:\archives\/$yyyymmdd$\ /m /s /yy This works quite well (without worrying about the name-collision with the separator character however small the chances are). I see little advantage in the directory-flattening feature if you do not exercise file-selection operation while the flattening operation is carried out. That is why I do not recommend the use of the feature if you just say "\src\*.*" with no more file-selection operation. (BTW, in my opinion the /M switch should never be used --- we keep it for the sake of XCOPY-compatibility but the archive-bit is too unreliable for any operations. We like the /BI switch much better than /M --- both has strength and weakness but practically speaking, /BI is much better). > Then if I could figure out how to simultaneously delete the > files that were older than 30 days, I see nothing imperative to perform the deletion "simultaneously". When an operation is getting more and more complicated, you should use a batch file script where there is no reason to do everything in one line of command. Use /RSY/DB#31 to delete files which are older than 30 days (In a separate command). I'm still trying to focus this message on the said-subject ---- the directory-flattening operation. But, Jim's concern has shifted from it to his strategy of backup operation. I have a feeling that Jim was trying to see whether the directory- flattening operation could be useful to his backup need. The answer is NO. At least not in the way he wants to conduct his backup operation. ------- Here we go. Kan's babbling starts here ----------- Lastly, let me comment on his idea of holding a set of files for 30 days before deleting them forever. Actually, many people want to do similar thing one way or another. We have never directly addressed the issue by providing a dedicated "switch" for that. And one day, we might add such a feature --- we have already talked about the "three-way" operation where we introduce a third argument (in addition to the \src\ and the \dst\ argument, we add the \ref\ argument) which specifies the reference directory. We are vaguely contemplating to design a scheme where the third directory will be used in a number of ways one of which is the so-called "junkyard" directory. The nickname was formed when we are responding to some user's wish where the zapped files (the ones that are to be removed by /Z) will be collected. In a sense, the third (junkyard) directory will be the place the removed file will be transferred rather than deleted permanently. The same thing will be true for files which would be overwritten. (Also, we like the name Junkyard because XXCOPY underutilizes the letter J in the XXCOPY switch set). This is our way of implementing the "Recycle-bin" which we have been deliberately staying away. Although the "junkyard" directory is not officially supported by any existing XXCOPY switch in an explicit way, you can implement the scheme quite well by combining the current set of switches (just do your own way, at least for now). Now, going back to Jim's (and many others') desire to place certain files in a "limbo" area where files are kept before permanently deleted --- where older files were purged in a systematic fashion, The implementation of the "30-day" holding of files that are to be deleted should be timed not by the file's so-called "last-write" date. But the 30-day countdown should be ideally started when the file is placed in the junkyard directory. In this case, you can take advantage of the little known feature that three distinctive timestamps are maintained by the file system for every file. File-creation time (the file is first created in the directory) File-last-write time (the file time that most of us use) File-last-access time (even a read-access is recorded). Here, by using the File-creation time, (/RSY/DB#31/FC) you may select files in the "junkyard" directory which have been there for more than 30 days. In this case, the /FC switch changes the meaning of the timestamp from the usual Last-write time (/FW) to the seldom-used File-creation (/FC) time. To make this scheme work all the time, you must make sure the file which you are bring into the holding area must been brought in as a new file there rather than overwriting an existing one. Please note that in this context, the "File-Creation" time is not the time the file was generated for the first time. Rather, it reflects the time when the file was brought into the current directory from elsewhere by copying. That is, the "File-Creation" time remains the same when you overwrite the file with any other file (of the same name). The name of this timestamp is very confusing indeed --- it is not our invention, but we just follow Microsoft's documentation. --------------------------------------------------------------- Unfortunately, due to Microsoft's poor documentation of the purpose and the exact implementation rules on the last-access feature, the timestamp is nearly useless. If the last-access time were restricted to that of the designated application, it could have been useful. But, when a file-access by such applications as XXCOPY is treated as read-access, the File-last-access time is nearly useless in our opinion. --------------------------------------------------------------- Kan Yabumoto ================================================================== At 2001-06-20 10:33, you wrote: > >>In most case, the files that are collected into the destination >directory of the flattening command should be regarded as temporary >and should be discarded after its use. Of course, this is one >good way to archive certain class of files on a semi-permanent basis.<< > >Right now, I am temporarily archiving files that are about to be >overwritten. I am creating a directory for the date and then using the /S >switch: > >xxcopy d:\personal\*.* d:\archives\/$yyyymmdd$\ /m /s /yy > >I might be better to "flatten" the structure into a single directory with a >file name that contains the date. Then if I could figure out how to >simultaneously delete the files that were older than 30 days, I would have a >pretty simple way to hold on to files "just in case" before deleting them >forever. > >Thanks for the detailed explanation, and other comments/suggestions will be >appreciated. > >James
This message if part of XXCOPY's message Archive. The archive contains all the messages posted at Yahoo!Groups: XXCOPY.