[cmake-developers] Windows symbolic links handling

Manu ianmalcom at gmail.com
Wed Aug 16 05:35:18 EDT 2017


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/9571214e55cb8b86dadb26b6b1d696ef488bdd4b

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20170816/3bfb2c63/attachment.html>


More information about the cmake-developers mailing list