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