Boost logo

Boost :

Subject: Re: [boost] big problem with dependency changes
From: Bjørn Roald (bjorn_at_[hidden])
Date: 2014-06-16 16:12:10

On 06/16/2014 07:42 PM, Paul A. Bristow wrote:
>> -----Original Message-----
>> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Bjørn Roald
>> Sent: 16 June 2014 17:28
>> To: boost_at_[hidden]
>> Subject: Re: [boost] big problem with dependency changes
>> On 06/16/2014 12:11 PM, Peter Dimov wrote:
>>> Glen Fernandes wrote:
>>>> On Mon, Jun 16, 2014 at 1:28 AM, Paul A. Bristow wrote:
>>>>> I'm glad I am not alone in having to nuke the /boost directory.
>>>>> Am I right to be worried about this? It should not happen? Why
>>>> does it > happen?
>>>> I've had no problems on my non-Windows (Linux, OSX) machines. I
>>>> regularly have to nuke /boost on Windows to get things to work.
>>> I'm on Windows and b2 has done a good job so far. I've only had to
>>> delete /boost maybe once. I usually don't even bother with "b2 headers"
>>> - everything seems to work without it. Go figure. :-)
>> For those of you that struggle with this when you use b2 on your system, You
> should
>> get a line at the beginning of the output saying:
>> - symlinks supported : yes
>> If not, b2 is not able to create symbolic links for individual files on your
> system.
>> There may be a number of reasons for this, but on recent MS Windows systems it
> is
>> usually related to user privileges, the tool used to create symbolic links
> require
>> elevated privileges.
>> If b2 are not able to create symbolic links for "b2 headers" targets, it will
> use hard
>> links or file copies. Both of these alternatives to symbolic links have
> severe issues
>> that could cause you to end up with stale files in the boost folder, or cause
> you to
>> edit files that are later overwritten by b2.
>> For enabling b2 use of symbolic links on windows, have a look at the following
>> information from the web (quoting from my posting 2 February on the same
> issue.):
>> refs:
>> ignored-on-windows-8
>> link-updated-security-policy-still-gives-pr
>> home-premium-as-a-regular-user
>> Most promising may be:
>> Provide SeCreateSymbolicLinkPrivilege privilege to the user who is running the
> script.
>> If the user is Administrator on the machine you may need to turn off UAC.
>> Note I have not tested any of this as I have no problems on my systems.
>> So please give feedback to the list if any of this work for you. Thanks.
> Thanks. This is very useful info.
> I didn't think it mattered if hard or soft links but clearly it does.

Well, it does under certain conditions:

A boost/foo/bar.h hard link may end up as a copy of a deleted file that
used to be at libs/foo/include/boost/foo/bar.h.

A boost/foo/bar.h hard link may also end up as a copy of an old version
of a changed file that used to be at libs/foo/include/boost/foo/bar.h.

Basically all regular files are hard links to the file content. The hard
link in the boost/foo/bar.h and its original are equivalent references
to the same file content. They have shared ownership to the file (aka.
shared_ptr). If the original is deleted, well, the file lives on as the
other hard link lives on. If the original is changed by first deleting,
then write to a new file with same name, then the boost/foo/bar.h hard
link point to the old version of libs/foo/include/boost/foo/bar.h.
Regrettably more tools than I expected do the later type of delete then
write sequence rather than in-place overwrite when editing files. Git
being one offender :-(

Symlinks are just forwarding one name to the target file path. Thus
neighter of the above problems causes real issues. You may still have
stale symlinks to deleted files, but accessing them would fail when
attempted as the original can not be found.

> Don’t'we need to change the instructions *always* "run from administrator"?

I don't know. Some users are concerned about running as Administrator,
and I am not sure I would recommend that at all.

Some users may not be allowed to be Administrators in a corporate

The problem seems to be that even if you are in the Administrator group,
you can not do this as your normal user in scripts. You have to elevate
the script, which I assume means you run everything in the script as the
Administrator user. That may be a poor idea.

Simply setting the SeCreateSymbolicLinkPrivilege for the user seems more
promising as general guideline, But there are two issues with that as well:

You have to be Administrator to set privelages, or you need help from
somebody that is. I would not think this is a problem for most boosters.

To change the policies:

- Launch secpol.msc via Start or Start → Run.
- Open Security Settings → Local Policies → User Rights Assignment.
- In the list, find the "Create symbolic links" item, which
   represents SeCreateSymbolicLinkPrivilege.
- Double-click on the item and add yourself (or the whole Users group)
   to the list.

The changes will apply when you log out and log in again.

If you are in the Administrators group, you also need to disable User
Access Control(UAC). I have no idea if that is a good idea. As this
only apply to members of the Administrator group, I guess using a
separate user account could be an alternative work around if you or your
sysadmin are concerned about turning UAC off.

To turn UAC off in Vista/Win7/8/8.1 see here:


Boost list run by bdawes at, gregod at, cpdaniel at, john at