Recent discussion here makes it reasonable, I think, to evaluate what the "correct" behavior of -m is. I believe that, if -m is truly to do "mirroring", then its behavior does need to change.
Currently, -m is a shorthand for -r -N, but does not perform a mirror operation in the traditional sense of the word. I think a (temporary) change to the documentation, pointing this out clearly, is a good idea. The suggestion to load the document from local storage, if it has not been updated, and then continue to walk the tree seems like a reasonable one. However, AFAIK, wget has no provision for loading local documents. [/me gets out can opener, picks up big can labeled "WORMS".] While we're on this topic, let's look at another, related facet of wget's behavior: that of using -m on an ftp:// protocol url, rather than an http:// one. This may both fuel some further discussion on what correct behavior is, and how we can achieve it without massive upheaval to the retrieval and traversal code. In particular, does wget parse and follow links in an HTML document, when that document is retrieved (using -r) via the FTP protocol? If not, why not? FTP presents an interesting case because because there are two independent concepts of traversal that can possibly be applied. One is based entirely upon metadata -- the filesystem content. The other, applicable (only) when one is retrieving HTML documents via FTP, is document content based, and is the model used when retrieving via HTTP. (HTTP presents the filesystem content as document content, if it presents it at all, so this "split-personality" effect isn't obvious like it is with FTP.) -- Alan E "Please rush me my portable walrus cleaning kit! Yes I am over 18, but my IQ isn't."
