[fpc-pascal] DoDirSeparators and special filenames on Windows

[Sven Barth]

Am 09.09.2013 13:31, schrieb Sven Barth:
> Am 08.09.2013 22:32, schrieb Tomas Hajny:
>> On Sun, September 8, 2013 19:32, Sven Barth wrote:
>>> On 08.09.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.
>>> The problem is not GetCurrentDirectory itself (this function and
>>> SetCurrentDirectory use the process's PEB lock to access the current
>>> directory which is stored inside the PEB as well), but that different
>>> threads could call SetCurrentDirectory with different values and thus a
>>> thread who expected the current directory to be a specific one might
>>> resolve a relative path (by using another WinAPI function) using a
>>> current directory set by a different thread.
>> I believe that there are three different things:
>>
>> 1) We have a sequence in GetDir implementation for Windows targets which
>> changes the current directory. While this is obviously necessary due to
>> limitations of the respective Win32/64 API for retrieving current
>> directory combined with characteristics of the supported path names, it
>> may not be expected by the programmers who may have no call to
>> SetCurrentDirectory within their code and thus expect no issues with
>> thread safety. I don't know if it is possible to use a critical 
>> section or
>> something like that to avoid switching to another thread during this
>> context, but it might be useful to think about it in my opinion.
> On Windows this is completely useless. A process has only *one* 
> current directory. The current-directory-per-drive ones are only 
> implemented inside the command line interpreter and other programs 
> that use the crt library (not to be confused with the crt unit). So 
> the calling of SetCurrentDirectory inside ExpandFilename is not only 
> not threadsafe, but doesn't result in something useful either!
Correction, there seems to be a bit more magic going on... I'll report back.

Regards,
Sven