I don't care much about this bug/feature, so I won't argue one way or the other, but I will point out that it often makes little sense to set the modification date-time on a destination directory to that of the source directory. For example, if not all the files in a directory are copied to the destination, then why should the mod date-time on the destination match that of the source, when the directory _contents_ are different? Setting the mod date-time on the destination to some old value can also confuse backup software on the destination system, if it thinks that a recently (created or) modified directory has not been modified recently, so it's not worthy of inclusion in an incremental backup.
Strictly speaking, a normal file can be copied to a different file system, but a directory is often (re-) _created_ on the destination file system, not really copied in the same way as a normal file. On VMS, the BACKUP utility normally creates destination directories with the current date-time, not the original. An exception is when using BACKUP /IMAGE, which always copies all files (to a previously empty destination), so a destination directory always has exactly the same contents as the source directory. Because of this file-directory difference, the default behavior of the next version of Info-ZIP UnZip is expected be to restore the mod date-time on an extracted file, but _not_ on an "extracted" (recreated) directory, but the user will have the option to get directory date-times restored as well as file date-times (or neither). VMS BACKUP knows a /IMAGE save set when it sees one, but UnZip has no way of knowing if an archived directory is complete, so it can't reliably decide whether it makes sense to restore directory date-times. Thus the user needs to specify the behavior. (The behavior of currently released UnZip is a mess, depending on the local OS.) If Wget can't be sure, either, then it may make some sense to have a separate option to cause directory date-times to be preserved, and let the user decide. Just a thought. > Why not move the action of setting of mtime point until after leaving > the directory? Given the existence of symbolic links (or if, for some other reason, the sender is not always well-organized in the way it sequences the copied files and directories), then the only safe time to set directory attributes is after all the files have been processed. I remember nothing, and I'm too lazy to look at the Wget code, but the same kind of problem arises with directory permissions. You can't create a read-only destination directory, and then proceed to populate it with files. Such permissions must be set after all the files have been processed. (That "all the files" is "all the files in that directory", but if a symlink can redirect a file from somewhere else, then "all the files" is really "all the files".) As usual, everything's complicated ------------------------------------------------------------------------ Steven M. Schweda sms@antinode-info 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547
