[fpc-pascal] DoDirSeparators and special filenames on Windows

[Tomas Hajny]

On Sun, September 8, 2013 14:17, Bart wrote:
> On 9/8/13, Tomas Hajny <XHajT03 at hajny.biz> wrote:
>
>> Why do you believe that ExpandFilename is not threadsafe (on Windows or
>> any other platform)?
> ..
>> The only platform specific part inside
>> ExpandFilename is a call to GetDir function retrieving the current
>> directory. If that is not 'threadsafe' by itself (on Windows), then your
>> statement is correct,
>
> And that is exactly the point.
> GetDir calls GetCurentDirectory and MS says (see:
> http://msdn.microsoft.com/en-us/library/windows/desktop/aa364934%28v=vs.85%29.aspx)
> that multithreaded applications should not call GetCurrentDirectory.

OK, I'll have a look at the MSDN link once I sit at some machine with a
bigger display than my phone.


>  > that some other thread may change the current directory during
> execution
>> of ExpandFilename - well, that may be the case, but that is not special
>> for Windows and it should be the responsibility of the programmer either
>> not to change the current directory in other threads,
>
> But GetDir just does that: it changes the current directory if it
> tries to find the current directory on a drive that is not the current
> drive.
> It then calls SetCurrentDirectory with only the drive letter, and
> calls GetCurrentDirectory again.

Good, thanks for the pointer. We may indeed want to add some safeguards to
the Windows GetDir implementation (or possibly check some alternative
solution for finding out the current directory on other drives).


> Why would I forbid my users to specify relative paths?
> How would you feel if, as Jürgen suggests we prepend anything with
> \\?\, you now cannot do a simple:
> C:\Devel\Foo>fpc bar.pas -Fu..\MyLib
> But you must do
> C:\Devel\Foo>fpc C:\Devel\foo\bar.pas -FuC:\Devel\MyLib, because the
> compiler is mutithreaded (this may be untrue, but just for the sake of
> the argument), so expanding the filename is unsafe?

Even if the compiler becomes multithreaded in the future (not the case
now), it should probably still handle the command line parameters within
one space and perform the translation to full paths there. After all, it
means that not only ExpandFilename is not threadsafe, but basically any
opening of a file (and other I/O operations working with file names)
wouldn't be threadsafe either. We will have to solve it somehow.


> For the record: I am not stating that this (handling '\\?\') _must_ be
> "fixed" in fpc, I am perfectly happy with "you should handle that on
> the users side", which would mean NOT calling DoDirSeparators (and any
> function that uses that) on such a filename.
> It would be nice however if a "formal" point of view from the fpc core
> team was given on this subject.

OK, that is a fair point. Let's wait for the opinion of others.

Tomas