[fpc-pascal] DoDirSeparators and special filenames on Windows

[Tomas Hajny]

On Mon, September 9, 2013 14:13, Sven Barth wrote:
> Am 09.09.2013 13:47, schrieb Sven Barth:
>> Am 09.09.2013 13:31, schrieb Sven Barth:
>>> Am 08.09.2013 22:32, schrieb Tomas Hajny:
 .
 .
>>>> 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.
> Ok, while a process does indeed only have a single current directory the
> kernel32 DLL is setting up environment variables to reference the
> current directories of other drives and resolves them when
> SetCurrentDirectory is called.
>
> My suggestion: Don't use the SetCurrentDirectory stuff inside GetDir
> anymore, but instead use GetFullPathName with the drive as parameter
> (see
> http://msdn.microsoft.com/en-us/library/windows/desktop/aa364963%28v=vs.85%29.aspx
> ). It's still not thread safe in sense of your (3) (but that is the
> programmer's problem anyway), but the GetDir function itself would be
> thread safe.
> Just in case: GetFullPathName is supported in Win9x and since Windows NT
> 3.0.

Yes, this is a good idea.

Actually, my testing (performed on WinXP; see attachment -
C:\WINDOWS\SYSTEM32 and D:\TEMP are assumed to exist) shows that calling
SetCurrentDirectory has no impact to the remembered values of current
directories on other (non-default) drives and only the directories valid
on startup are used (I used the *A variants of Win32 API calls, but I hope
that this shouldn't make a difference). This raises a question if we
shouldn't update the environment variable ourselves within ChDir, because
as of now the behaviour is different compared to other platforms (e.g. the
first test program compiled for DOS and Windows gives different results
when run on the same Windows machine).

If we decide _not_ to change the ChDir behaviour (i.e. not to set the
environment variable), we also need to decide whether to prefer
GetCurrentDirectory or GetFullPathName result if the requested drive
matches the current one, because the results would differ in cases like
this:

 ChDir ('C:\WINDOWS\SYSTEM32');
 GetDir (3, S);

If the current directory for C: is e.g. C:\ on startup, GetFullPathname
returns C:\, whereas GetCurrentDirectory returns C:\WINDOWS\SYSTEM32.

Tomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.zip
Type: application/zip
Size: 945 bytes
Desc: not available
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20130909/37303661/attachment.zip>