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

[Eli Zaretskii]

> Date: Sun, 23 Aug 2015 17:16:37 +0200
> From: Ángel González <address@hidden>
> CC: address@hidden
> 
> 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}}

For what part do you need a reference?

> I'm quite sure explorer will happily work with UNC paths, which means
> the user will be able to flawlessly move/copy/delete them.

No, the Explorer cannot handle files longer than 260 characters.  The
Explorer uses shell APIs that are limited to 260 characters.

Like I said: creating files whose names are longer than 260 characters
is asking for trouble.  You will need to write your own programs to
manipulate such files.

> And actually, I think most programs will happily open (and read,
> edit, etc.) a file that was provided in UNC format.

UNC format is indeed supported by most (if not all) programs, but as
soon as the file name is longer than 260 characters, all file-related
APIs begin to fail.

> >>>> * _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.

Why not?  Here's a simple code snippet that should work:

  int
  open_utf8 (const char *fn, int mode)
  {
    wchar_t fn_utf16[32*1024];
    int result = MultiByteToWideChar (CP_UTF8, MB_ERR_INVALID_CHARS, fn, -1,
                                     fn_utf16, 32*1024);

    if (!result)
      {
        DWORD err = GetLastError ();

        switch (err)
          {
          case ERROR_INVALID_FLAGS:
          case ERROR_INVALID_PARAMETER:
            errno = EINVAL;
            break;
          case ERROR_INSUFFICIENT_BUFFER:
            errno = ENAMETOOLONG;
            break;
          case ERROR_NO_UNICODE_TRANSLATION:
          default:
            errno = ENOENT;
            break;
          }
        return -1;
      }
    return _wopen (fn_utf16, mode);
  }

> And we would be risking a stack overflow if attempting to create
> such buffer in the stack.

The default stack size of Windows programs is 2MB, so I think we are
safe using 64K here.