"Permission denied" on new commit after revert and uncommit

Should have mentioned that there seems to be nothing amiss with the NTFS permissions; I'm the owner and have full control (inherited from the drive permissions).

It's a very transient bug.
On the 3rd commit (since the revert and uncommit), no error message, all seems to be back to normal.
(I did exit and restart Bazaar Explorer after each error, if that's what you're thinking.)

jon h пишет:
> It's a very transient bug.
> On the 3rd commit (since the revert and uncommit), no error message, all seems to be back to normal.
> (I did exit and restart Bazaar Explorer after each error, if that's what you're thinking.)

Please, test new version of Bazaar Explorer 1.2.2 and tell us whether
the problem still exists.

--
All the dude wanted was his rug back

I have something similar which has started happening recently. Bazaar Explorer 1.2.2, QBzr 0.22.1, bzrlib 2.5.0 (should be all latest versions).

Steps to repeat:
(1) Edit a file held in a Bazaar Repository on a Win7 64-bit machine (latest everything). Confirm in Bazaar Explorer that the file has changed, but do not commit it. You can in fact safely commit it and un-commit it without causing problems, that's not the defect.

(2) Using Bazaar Explorer, revert the change.

(3) Open Windows Explorer and look at the file...
You see the ~1~ version, but also the original file, except it has a little "lock" icon on it. The reason is that the file's security permissions are changed - it no longer "includes inheritable permissions from this object's parent".

The work-around:
(a) Find the file, right-click, select "properties".
(b) Click "security"
(c) Click "Advanced". Note that "include inheritable permissions from this object's parent" is not checked.
(d) Click "Change permissions..."
(e) Click "include inheritable permissions from this object's parent"
(f) Press "Ok" to everything. Note that the little lock has now gone away.

I think then that Bazaar is re-creating that original (reverted-to) file and it's not setting the permissions on it to match the required output file.

I think this may be the same issue as above, but if it's not then apologies and I'll report it elsewhere.

philw пишет:
> I think then that Bazaar is re-creating that original (reverted-to) file
> and it's not setting the permissions on it to match the required output
> file.

I'm sure that Bazaar (bzr CLI) is re-creating file while doing revert.
And I'm sure that Bazaar does not know how to set the right permissions.

> I think this may be the same issue as above, but if it's not then
> apologies and I'll report it elsewhere.

I think that you has described quite different bug, and I suggest you to
file new bug report against Bazaar itself.

As a workaround one can try to implement different revert strategy in
QBzr without touching Bazaar core: copy modified file to *.~1~ and then
overwrite your file in-place. I'm not quite sure it will work in 100%
cases, but at least you'll have some way to avoid this permissions problem.

Another workaround would be to cat old content on top of modified file, e.g.

bzr cat foo.txt > foo.txt

Not very elegant, but should work too.

--
All the dude wanted was his rug back

Ok, I'll raise another defect. The point is that the reverted-to file must have the same "inherit" status as the file it's reverting. If it does not, then... the file permissions will go bad: the reversion is in fact wrong, because it restores the file contents but not the file state, which it trashes.

The effect is to make "revert" a painful operation. There are work arounds as you suggest, or just manually re-set the permissions (the inheritance flag) every time you revert something.

I'll raise it separately.

philw пишет:
> Ok, I'll raise another defect. The point is that the reverted-to file
> must have the same "inherit" status as the file it's reverting. If it
> does not, then... the file permissions will go bad: the reversion is in
> fact wrong, because it restores the file contents but not the file
> state, which it trashes.
>
> The effect is to make "revert" a painful operation. There are work
> arounds as you suggest, or just manually re-set the permissions (the
> inheritance flag) every time you revert something.
>
> I'll raise it separately.

Please add this comment to your new bug.

--
All the dude wanted was his rug back