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

[Ángel González]

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.