Subject: Re: [boost] Making Boost.Filesystem work with GENERAL filenames with g++ in Windows (a solution)
From: Alf P. Steinbach (alf.p.steinbach+usenet_at_[hidden])
Date: 2011-10-26 06:59:18
On 26.10.2011 12:24, Yakov Galka wrote:
> On Wed, Oct 26, 2011 at 11:56, Alf P. Steinbach<
> alf.p.steinbach+usenet_at_[hidden]> wrote:
>> On 26.10.2011 11:47, Artyom Beilis wrote:
>>> That is what very good about stream buffers... You can implement anything
>>> you need.
>> If the authors of Boost.Filesystem are happy to reimplement stream buffers
>> from scratch, all the way, then that would indeed be good news.
>> But do you *really* think that is realistic?
> I think when someone gives you a working implementation, it's rather dumb to
> ask if it's realistic or not.
Let me try to clarify what I meant, then.
Artyom's suggestion, as I understand it, is to forsake each compiler's
streambuf implementation and use a Boost-provided general one that
extends the standard's interface. With that Boost implementation
building on some non-standard extension such as _wfopen, or implementing
buffers from scratch, all the way. Which in the general case will be
necessary, and thus, no point in also using extensions.
Now is that realistic?
>> Using short file names is no go for two reasons:
>>> 1. It works only when file exists (can't create new file)
>>> 2. It is quite deprecated
>> Both points are incorrect.
>> Regarding (1), did you notice that I wrote "full source code provided"...?
> Yes, you provide a hackish workaround, that is vulnerable to a
> race-condition btw.
No, AFAIK there is no extra realistic vulnerability.
There is a vulnerability, yes, but it's there anyway.
And there is a non-realistic (extremely low probability) vulnerability
that process A attempts to create a non-existing file F, while process B
tries to delete F. In this case creating F might fail /also with the
fix/. But arguing that the fix is "hackish" because it fails to fix such
an esoteric case, is IMO not serious.
> Even a more serious problem is that it doesn't work with
> paths longer than MAX_PATH.
The vague impression you have in that direction is in a sense valid,
that there is something fishy there, because with the fix one may
conceivably have a problem that a path that is longer than MAX_PATH
works, when by rights it should not (I have not tested this though).
1 It is trivial to restrict narrow character path lengths to
MAX_PATH so that that problem does not occur.
2 It is only where the existing implementation fails to access
a too long path, that the fix may fail to erroneously fix it.
3 It is not a good idea to use Windows paths longer than MAX_PATH
since Windows Explorer and many other tools do not support them.
Unless you want your application to create unusable files.
In short your "serious problem" has it backwards as to what the problems
are, and the fix does not introduce any restriction.
>> I think when something demonstrably works, it's rather dumb to assert that
>> it can't work, sorry.
>> But considering that Boost.Filesystem is slated for later inclusion in the
>>>> standard library (or at least into TR2), I think it would be nice if it
>>>> is able
>>>> to give access to all accessible files in Windows, also with g++,
>>> This is a problem that can be fixed easily in Boost.Filesystem.
>> Yes, I think so, for Windows.
>> However, more important, the existence of an actual fix (which I linked to)
>> shows that the present interface does not prevent a fix for Windows.
>> For some other OS-es it may not necessarily be easy to fix, however, and
>> thus, for inclusion of Boost.Filesystem in the standard library I think that
>> should be thoroughly investigated.
> Personally I think that boost::filesystem::paths are a sad joke, it's a pity
> they're heading to the standard. Although the OS-part is definitely good,
> the way path class is design isn't suitable for paths outside the unix
> world. Even if you fix the Unicode problems, you still cannot use long paths
> on windows (longer than MAX_PATH), although they are supported by the OS.
> Moreover, judging by the last fixes to the library, it looks like Beman
> wants to shift the burden of this on the user of the library, instead of
> implementing something that works transparently.
Hm, I haven't used the path class.
However the MAX_PATH issue is not really an issue in practice.
The *only* uses I have seen of paths longer than MAX_PATH, have been
silly script-kiddies trying to create problems for people running FTP
servers. And that's because the ordinary tools can't handle them, thus,
difficult to remove the script-kiddie's nested folders. Conversely, as a
serious software developer one should stay well away from such paths.
Cheers & hth.,
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk