Boost logo

Boost :

Subject: Re: [boost] [filesystem] Junction support on Windows?
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-01-02 06:44:11


On 30 Dec 2014 at 15:45, Peter Dimov wrote:

> Filesystem provides support for hard and symbolic links, but on Windows,
> hard links do not work on directories and symbolic links do not work for the
> majority of users because they require elevation by default.

Not quite true. Creating symbolic links requires the user to have
that privilege. Any user may have it. I have been known to grant that
permission to the guest user on CIs testing Boost :)

> That is why, for example, "b2 headers" was changed to also use junctions, if
> possible.
>
> But if I, for another example, want to replicate "b2 headers" from a C++
> program using Filesystem, I can't, because it offers no junction support.
>
> Should create_directory_symlink be enhanced to create a junction, if
> CreateSymbolicLink is not available or fails with ERROR_ACCESS_DENIED?

AFIO's symlink parsing code will consume both junctions and symbolic
links equally, but symlink creation always uses junctions for
directories and symbolic links for files (currently a todo item). I
think that is the only sane solution which somewhat matches POSIX
symlink behaviour.

You may find the following implementation code useful:

AFIO's junction parsing code:

https://github.com/BoostGSoC13/boost.afio/blob/develop/include/boost/a
fio/detail/impl/afio_iocp.ipp#L150

AFIO's junction creation code:

https://github.com/BoostGSoC13/boost.afio/blob/develop/include/boost/a
fio/detail/impl/afio_iocp.ipp#L322

Note that AFIO exclusively works in 32k NT kernel filesystem paths
and therefore some extra work may be needed for 260 char limit paths.
Personally speaking I'd just love if the Filesystem TS mandatorily
abandoned 260 char path limits on Windows, supporting them is
completely unnecessary.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/



Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk