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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk