Re: [boost] big problem with dependency changes

Subject: Re: [boost] big problem with dependency changes
From: Bjørn Roald (bjorn_at_[hidden])
Date: 2014-06-17 00:38:49

On 06/17/2014 03:04 AM, Gavin Lambert wrote:
> On 17/06/2014 08:12, Bjørn Roald wrote:
>> 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 :-(
>
> It's likely to be defensive programming.  Writing to a temporary file
> with an alternate name and then executing a delete-rename or
> rename-rename-delete sequence is generally as close as you can get to an
> atomic update that doesn't leave behind partial files in case of failure
> (thereby possibly destroying content), at least without "real"
> transaction support (which does exist but is rarely used in Windows).
> (This is because writes are slow, but deletes and renames are nearly
> instant and are less likely to fail.)

Yes you are right, have done that many times in my own code.

> Thus you'll find version-control systems and other software designed for
> reliability will do that more often than not, although it's more
> hit-n-miss with general-purpose applications (eg. editors).

In fact it was a discussion on the git developer list on the issue, and 
they decided to ignore the fact that they knew they would break hard 
links.  I think the rationale was partly performance and partly the fact 
that it would not help much anyway.  Other tools would break hardlinks 
and the reliance on hard links would be broken anyway.

> And most Windows software is not written to be symlink-aware because
> they're very rare.

Did you mean hard-link aware?  In my mind, whether they are symlink 
aware or not would not make much of a difference.

>> 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.
>
> In general, it is not a good idea.  While Linux users (and more
> importantly, applications) are used to the idea of logging in to a
> completely separate account for day-to-day vs. admin operations, Windows
> users (and applications) generally expect to use the same account for
> both.  UAC allows the distinction between elevated or not, which lets
> the non-admin tasks be run more safely (like Linux).  While it's
> possible for a sufficiently disciplined user to run dual accounts like
> on Linux, this often confuses applications in unexpected ways.

Yes, I would not like to give the general advice to turn UAC off, what 
people elect to do is their own business.  But this leaves us with a 
problem for "b2 headers" on Windows, as we have no clear advice of how 
to deal with lack of symlink support that is simple, easy and secure. 
At least unless you are happy about not being in the Administrators group.

The situation can be improved by making the "b2 header" targets proper 
targets in b2.  For performance reasons, a shortcut is used currently I 
think. I believe that is also the reason you sometimes need to call "b2 
headers" explicitly. Further b2 could detect hardlinks that has become 
copies in the boost folder.  Although this would be an improvement, and 
it would fix build issues, it is not close to as good as symbolic links. 
Orphaned hardlinks to deletad header files would still be  a potential 
problem.  Also, other tools and the user will still suffer. There is a 
window from the hardlink relation is broken to next time you build where 
bad things may happen.  E.g. you edit in the wrong file, and then your 
work is overwritten.

Still looking for proper user level symlink support on windows.
--
Bjørn