bug-wget
[Top][All Lists]
Advanced

[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
>
> --



reply via email to

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