On 06/16/2014 07:42 PM, Paul A. Bristow wrote:
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Bjørn Roald Sent: 16 June 2014 17:28 To: boost@lists.boost.org 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: http://stackoverflow.com/questions/15320550/secreatesymboliclinkprivilege- ignored-on-windows-8
http://msdn.microsoft.com/en-us/library/bb530410.aspx
http://superuser.com/questions/148937/windows-server-2008-create-symbolic- link-updated-security-policy-still-gives-pr
http://superuser.com/questions/124679/how-do-i-create-a-link-in-windows-7- 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 environment. 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: 1. 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. 2. 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: http://www.howtogeek.com/howto/windows-vista/disable-user-account-control-ua... -- Bjørn