Shall we support very long pathnames (>260) in common UI interface
(FileOpen dialog, Shell32.dll, etc)?
In FileOpen dialog user pass length of output buffer, so theoretically
FO can support long names.
The bottleneck here is Shell32 interface which is mostly limited to
MAX_PATH names by design. There are few functions in Shell32 returning names
"at least" (and apparently "at most") MAX_PATH chars long. Also there are
set of functions returning names as LPSTRRET structure. I'm not quite
familiar with shell stuff, but according to MSDN uType field is "Value that
specifies the desired format of the string." Currently all functions don't
honour input uType and always use STRRET_CSTR type. So probably we can
modify them to support STRRET_WSTR which is allocated by shell and can hold
long names. It's not quite convinient because Wine internally uses ANSI
strings. Second choice is to have alternative (internal) shell interface
which supports pathnames of any length.
Last choice is to follow Microsoft's strategy and disable access to
folders with pathnames longer than MAX_PATH. FO dialog and Windows Explorer
show error message "Can't access this folder. Path is too long." when you
try to enter such directories.
As for me I don't like last choice. But considering that there are still
a lot of programmers whose brains are damaged by 8.3 file system, it could
be more safe solution. From the other hand we can add one more command-line
switch to allow support of arbitrary path names in common UI. Also for
FileOpen dialog we can rely on requested buffer size and enable/disable long
name support dynamically.
--
Serge Ivanov
[EMAIL PROTECTED]
--
The address in the headers is not the poster's real email address. Do not send
private mail to the poster using your mailer's "reply" feature. CC's of mail
to mailing lists are OK. Problem reports to "[EMAIL PROTECTED]".
The poster's email address is "[EMAIL PROTECTED]".
