bug-wget
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Is there a possibility for wget to handle long(er) paths?


From: D . Wróblewski
Subject: Is there a possibility for wget to handle long(er) paths?
Date: Wed, 2 Oct 2024 01:59:42 +0200

I am using wget for a local backup of a remote ftp/s directory using the
following syntax:

   wget --no-dns-cache -nv -r -c -l inf -P/local_dir -nH --cut-dirs=1
--restrict-file-names=windows --progress=dot:mega --ftps-implicit (...)

This is wget 1.21 on Raspbian GNU/Linux 11 (bullseye)
   # wget --version
   GNU Wget 1.21 built on linux-gnueabihf.
I am restricting file names to windows because the local directory is
shared via smb to a Windows PC.

The problem I encountered is that some files inside the remote directory
tree have long paths.

In such a case, wget prints:
   The name is too long, 240 chars total.
   Trying to shorten...
and it downloads the file with its name shortened.

If a local filesystem has no support for long paths, this behaviour is some
necessary workaround and is appreciated.

However, in my case, the local filesystem does support long paths. I can
create paths much longer than 240 characters with mkdir, cp, mc, and so on.
So the name length restriction introduced by wget is unnecessary and causes
problems: some files end up without extensions, some names are cut at the
dot ('.') character and then their names are not showing properly via smb.

Is there a parameter enabling wget to use longer path names?
If not, is it possible to introduce it in the next wget version?

Best regards,
Glorifyday

--


reply via email to

[Prev in Thread] Current Thread [Next in Thread]