[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
--
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Is there a possibility for wget to handle long(er) paths?,
D . Wróblewski <=