bug-wget
[Top][All Lists]

## Re: [Bug-wget] bad filenames (again)

 From: Ángel González Subject: Re: [Bug-wget] bad filenames (again) Date: Sun, 23 Aug 2015 17:16:37 +0200 User-agent: Thunderbird

On 23/08/15 16:47, Eli Zaretskii wrote:

Wrong. I can work with a larger one by using a UNC path.

But then you will be unable to use relative file names, and will have
to convert all the file names to the UNC format by hand, and any file
names we create that exceed the 260-character limit will be almost
unusable, since almost any program will be unable to
read/write/delete/copy/whatever it.  So this method is impractical,
and it doesn't lift the limit anyway, see below.

{{reference needed}}

I'm quite sure explorer will happily work with UNC paths, which means
the user will be able to flawlessly move/copy/delete them. And actually,
I think most programs will happily open (and read, edit, etc.) a file that
was provided in UNC format.


* _Some_ Windows when using _some_ filesystems / apis have fixed limits,
but there are ways to produce larger paths...

The issue here is not whether the size limits differ, the issue is
whether the largest limit is still fixed.  And it is, on Windows.

I had tried to skip over the specific details in my previous mail. I
didn't meant that
the limit would be bigger, but that there isn't one (that you can rely
on, at least). On
Windows 95/98 you had this 260 character limit, and you currently still
do depending
on the API you are using. But that's not a system limit any more.

This is wrong, and the URL I posted clearly describes the limitation:
If you use UNCs, the size is still limited to 32K characters.  So even
if we want to convert every file name to the UNC \\?\x:\foo\bar form
and create unusable files (which I don't recommend), the maximum
length is still known in advance.

Ok, it is possible that there *is* a limit of 32K characters. Still, it's not a
practical one to hardcode. And we would be risking a stack overflow if
attempting to create such buffer in the stack.