Re: [Bug-wget] wget mirroring not syncing FTP directories timestamps

[Steven M. Schweda]

   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               address@hidden
   382 South Warwick Street        (+1) 651-699-9818
   Saint Paul  MN  55105-2547