[fpc-pascal] DoDirSeparators and special filenames on Windows

Sven Barth pascaldragon at googlemail.com
Mon Sep 9 13:46:50 CEST 2013


Am 09.09.2013 13:25, schrieb Sven Barth:
> Am 08.09.2013 22:13, schrieb Mattias Gaertner:
>> On Sun, 08 Sep 2013 19:32:23 +0200
>> Sven Barth <pascaldragon at googlemail.com> 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)?
>>> [...]
>>>> 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.
>>>
>>> So this can not be solved by using a lock inside ExpandFilename and
>>> might happen on other systems as well as long as the current directory
>>> is not stored per thread.
>> Actually the problem is that Windows has multiple current directories,
>> but you can only read the one of the active drive.
> This. Is. Wrong.
>
> MSDN remark for Set-/GetCurrentDirectory: Each process has a single 
> current directory that consists of two parts: ...
>
> The current directory per drive is only for the command interpreter 
> and programs that use the crt library (not to be confused with our crt 
> unit).
Correction, there seems to be a bit more magic going on... I'll report back.

Regards,
Sven



More information about the fpc-pascal mailing list