[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Is there a possibility for wget to handle long(er) paths?
From: |
Darshit Shah |
Subject: |
Re: Is there a possibility for wget to handle long(er) paths? |
Date: |
Mon, 11 Nov 2024 16:57:59 +0100 |
Hi,
Sorry for the delayed response.
Would it be possible for you to please share the full output of Wget?
Also, the output of `wget --version`.
GNU Wget does not usually impose arbitrary limits on the file name / path
length.
The limits that are imposed are done so by querying pathconf(3)
In case pathconf is not available, a conservative limit on the path length
is enforced. Which seems to be the case on your system.
Given that pathconf(3) is part of POSIX-1.2008, I'm at a loss trying to explain
why it wasn't found on your system.
I will try to see if I can replicate your environment. But until then, there
isn't
much we can do about this. I would not add a runtime parameter for this. If no
solution can be found, I am willing to add a compile time knob to modify the max
path lengths. But that will still require you to rebuild Wget for your target
platform
manually.
On Wed, Oct 2, 2024, at 01:59, D. Wróblewski wrote:
> 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
>
> --
- Re: Is there a possibility for wget to handle long(er) paths?,
Darshit Shah <=