Comment 2 for bug 825732

Apparently this is "by design". It's not perfect, but one has to live with it. This has to do with bzr trying to do atomic updates of the file system by using renames. However, it is fixable by keeping track of the file permissions and doing chown (possibly asking for sudo if necessary). Can I suggest adding this as an option, and enabling this option by default? I cannot come up with any usecases that would break because of such an addition.

If the suggestion seems sane, please change this to a feature request instead.

log from #bzr:

<cheater__> i have isolated the reason for the bug
 https://bugs.launchpad.net/bzr/+bug/825732
<ubot5> Error: ubuntu bug 825732 not found
<cheater__> ah yes, it's a security bug, it won't be accessible publicly
 i'm not sure if i should make it public
<maxb> My inclination is that this is not a bug
<cheater__> how so? it clobbers ownership of the file
 no other operations do that
<maxb> Simply that your expectations disagree with the design goals of most version control tools
<cheater__> it's not homogenous in its behavior
 other operations do not do this
 just shelve (that i know of)
<maxb> No, try bzr revert for example
<cheater__> hm
 what others do that?
 and which ones don't?
<maxb> pretty much anything that changes the file via the generic treetransform code
<cheater__> is there a reason to overwrite the file instead of updating it?
 if not, maybe i can make a patch (if htat part is in python and not, say, C)
<maxb> Yes, bzr prepares all of the updates it is going to do within .bzr, and then moves files in and out to commit the result of the operation in a nearly atomic fashion
<cheater__> mhm
 i understand that a rename is atomic while a write doesn't have to be
 i wonder if there could be a plugin which takes note of the ownership, and chown's the files (and asks you to sudo if necessary)
<maxb> Not entirely impossible, I suppose, though it does sound like it would have to hook very deeply into the core. I doubt sufficient hooks are available now