[cmake-developers] Windows symbolic links handling

[Manu]

Hello,

I have fixed it but I am struggling with the new policy. The behaviour
change goes into cmSystemTools::GetRealPath implementation and SystemTools
has no context, so I am not sure how to check the policy.

Mimicking policy CMP0067 usage, I could create an old and a new version of
GetRealPath and check for the policy prior calling it all along the code.
On the other hand, I could pass the policy status as a parameter to every
GetRealPath call. Which is the proper way?

To perform a pull request, should I previously open an issue about this or
it is enough with the discusion here in the mailing list.

Regards.



2017-08-16 11:35 GMT+02:00 Manu <ianmalcom at gmail.com>:

>
>
> 2017-08-15 16:43 GMT+02:00 Brad King <brad.king at kitware.com>:
>
>> On 08/14/2017 06:35 AM, Manu wrote:
>> > Recently I migrated from cmake 2.8.12 to cmake 3.8 and FILE(TIMESTAMP
>> ...)
>> > behaviour changed. Now it reports symbolic link timestamp instead of
>> pointed
>> > file timestamp.
>>
>> Can you track down when that happened?
>>
>>
> I happened in release 3.1.0, back 2014. The commit which changed behaviour
> was this:
>
> https://github.com/Kitware/CMake/commit/9571214e55cb8b86dadb26b6b1d696
> ef488bdd4b
>
> In source file Source/cmTimestamp.cxx, stat call was replaced by kwsys ModifiedTime
> call. kwsys relies in system function GetFileAttributesExW which do not
> resolve symlinks, however stat does (in spite of not being documentented in
> MSDN).
>
> Removing the #ifdef WIN32 clause in ModifiedTime and using stat call
> resolves the problem, nevertheless, this change does not resolves
> get_filename_compoment symlinks issue in Windows. The problem here is again
> in kwsys, which uses system call GetFullPathNameW (which do not resolves
> symlinks) instead of GetFinalPathNameByHandleW (which does).
>
> Despite of being two different commands, I think they are very related in
> this issue and the change should be make together.
>
>
>> > patch to fix both get_filename_compoment and FILE(TIMESTAMP ...)
>> >
>> > What troubles me is that symlink under Windows is a feature introduced
>> in
>> > Windows Vista and the change for handling them will break Windows XP
>> > compatibility. Is this acceptable?
>>
>> We still support running on XP.  If any newer Windows APIs are needed they
>> need to be looked up dynamically.  Also, behavior changes for existing
>> commands
>> may need a policy.
>>
>>
> I did not dig into cmake policies development but I am willing to submit a
> patch which includes a new policy as soon I can piece it up all together.
>
>
>> See also https://gitlab.kitware.com/cmake/cmake/issues/16926 for
>> discussion
>> of symbolic link APIs.
>>
>> -Brad
>>
>
> Manuel.
>



-- 
La victoria puede ser creada  -  Sun Tzu.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170824/28310582/attachment.html>