[Lazarus] Absolute paths on different platforms

[Sven Barth]

On 26.06.2011 19:40, Hans-Peter Diettrich wrote:
> Sven Barth schrieb:
>> On 26.06.2011 13:50, Hans-Peter Diettrich wrote:
>>> Mark Morgan Lloyd schrieb:
>>>
>>>> Does Windows still support commands like "subst" and "join"?
>>>
>>> A friend uses SUBST e.g. for his own libraries, and he cannot use
>>> FPC/Lazarus because these are unable to find his files in e.g. X:\.
>>>
>>
>> Why can't he use that? SUBST uses the same mechanism that is used for
>> e.g. C:\ so all folders that are mapped using SUBST (or its underlying
>> API) are accessible the same way from the Windows API as "normal"
>> drives are.
>
> AFAIR FPC/RTL could not find files in a root directory, e.g.
> X:\myfile.pas. This may be due to the missing ".." entry in "normal"
> drive root directories.
>

I should test that sometimes...

>>>> Alternatively I believe that it does now have an equivalent of
>>>> symlinks for directories.
>>>
>>> NT is POSIX compatible, at least with regards to files and inodes.
>>> Symlinks exist since the introduction of desktop shortcuts/icons and the
>>> Windows Explorer, in all file systems. The implementation (of symlinks
>>> and SUBST) may vary, though, depending on the concrete filesystem.
>>
>> But shortcuts aren't the same as symlinks. Shortcuts are normal files
>> and they can be opened like that using e.g. OpenFile while you need to
>> use special APIs to work on symlinks.
>
> Maybe, but when I "open" an shortcut to an folder, I get the folder
> contents, and its "properties" are the folder properties. Files may have
> different shortcuts/symlinks, but these can be replaced by hard links,
> in many cases (NTFS...).

But not when you use normal Windows API functions. There a shortcut file 
looks like a normal file. Window Explorer handles them in a special way. 
This is THE difference to symlinks. On POSIX basic APIs like "open" will 
be applied to the target of the symlink not the symlink itself.

Regards,
Sven