wget not converting links

Question

I am trying to mirror a fairly large site (20,000+ pages) prior to a major overhaul. Basically, I need a backup before cutting over to the new one in case we forgot something we need (we'll have about 1,000 pages at launch). The site is run on a CMS that I cannot easily extract usable data from, so I'm trying to make the copy with wget.

My problem is that wget does not appear to be actually converting links, despite the presence of --convert-links or -k in the command. I've tried a couple of different combinations of flags, but I haven't been able to get the output I need. Most recent failed attempt was:

nohup wget --mirror -k -l10 -PafscSnapshot --html-extension -R *calendar* -o wget.log http://www.example.org &

I've also included the --backup-converted, and --convert-links instead of -k (not that it have mattered). I've done it with and without -P and -l, again no that they should matter.

Results in files that still have links like:

http://www.example.org/ht/d/sp/i/17770

Solution 1

This is an old post, but I'm putting the answer here for future searchers.

The --convert-links feature happens only after the site download is complete. I would guess that, with such a large site, you tried to stop the process after a few pages were completed and therefore the process hadn't kicked off yet.

See also https://stackoverflow.com/questions/6348289/download-a-working-local-copy-of-a-webpage

From the wget docs

‘-k’
‘--convert-links’
After the download is complete, convert the links in the document to make them suitable for local viewing. This affects not only the visible hyperlinks, but any part of the document that links to external content, such as embedded images, links to style sheets, hyperlinks to non-html content, etc.

Each link will be changed in one of the two ways:

    The links to files that have been downloaded by Wget will be changed to refer to the file they point to as a relative link.

    Example: if the downloaded file /foo/doc.html links to /bar/img.gif, also downloaded, then the link in doc.html will be modified to point to ‘../bar/img.gif’. This kind of transformation works reliably for arbitrary combinations of directories.
    The links to files that have not been downloaded by Wget will be changed to include host name and absolute path of the location they point to.

    Example: if the downloaded file /foo/doc.html links to /bar/img.gif (or to ../bar/img.gif), then the link in doc.html will be modified to point to http://hostname/bar/img.gif. 

Because of this, local browsing works reliably: if a linked file was downloaded, the link will refer to its local name; if it was not downloaded, the link will refer to its full Internet address rather than presenting a broken link. The fact that the former links are converted to relative links ensures that you can move the downloaded hierarchy to another directory.

Note that only at the end of the download can Wget know which links have been downloaded. Because of that, the work done by ‘-k’ will be performed at the end of all the downloads. 

Solution 2

I have the same with a 6Gig site I'm trying to backup. After a few days, wget finishes, without an error message, and exit status 0, but without converting the links. Doing a smaller retrieval with the same options works fine. It's as if an internal table of whats been downloaded gets washed or corrupted before wget ends.

I'm going to try refetching the site with -nc (which shouldnt refetch anything, because it's already been downloaded, and finish off with converting the links - see Make wget convert HTML links to relative after download if -k wasn't specified )

Solution 3

Maybe you've run into wget -k converts files differently on Windows & Linux due to OS filename restrictions?

Comments

[commonpike]

.. but that didnt work. -nc was clobbering because of the -E option (even with -K on).

[Matthijs Kooijman]

I tried a similar thing, and wget rejected the combination of -nc and -k (apparently since wget 1.13, see savannah.gnu.org/bugs/?31781).

[Matthijs Kooijman]

Did you mean -O (redirect content) rather than -o (redirect wget progress output)? The OP used the latter, which should not affect -k AFAICS (just combined them successfully with wget 1.20).