bzr pull fails on windows if a file is locked

[Andrew King]

If a file happens to be open and is locked (eg. open with Word or Visual Studio), doing a bzr pull fails with the error message:

bzr: ERROR: [Errno 22] Invalid argument: u'Some file name'

What is more, every other file modified in that pull (by someone else) is listed as missing, and is deleted from the file system. This means that if you are in the middle of something, your repository becomes useless, because you cannot tell what changes you have lost, and if you happen to have local modifications to one of those files, those changes are lost. This means that people have to be very careful before doing a pull, as it is sometimes not obvious if an app has a file locked. This makes bzr very risky to use on windows.

Steps to reproduce:

(in a command prompt)

mkdir temp
bzr init
(edit temp.txt)
bzr add temp.txt
bzr commit temp.txt

mkdir temp2
cd temp2
bzr branch ../temp

open editing file in temp2\temp with Word

make changes in temp version
bzr commit in temp

bzr pull in temp2\temp

error:
bzr: ERROR: [Errno 22] Invalid argument: u'C:/temp2/temp/temp.txt'

This does not show the implications to other files in the pull, but adding that is trivial ...

[John A Meinel (jameinel)]

Should this be upgraded to High importance?

[Andrew King (eurokang)]

As this bug can lead to lost work, I would mark it high importance.

If people are using visual studio, because of the way intellisense runs at
random times, the only safe way of doing a pull is to close visual studio,
do a pull, then reopen it. This is quite annoying obviously, but the
consequences of forgetting to do it are very bad. You can potentially lose
all your work since the last check in. For other windows users I am not as
sure that it would be such a problem, but it could be, especially since it
only requires one locked file to break the entire checkout.

[Andrew King (eurokang)]

As this bug can lead to lost work, I would mark it high importance.

If people are using visual studio, because of the way intellisense runs at random times, the only safe way of doing a pull is to close visual studio, do a pull, then reopen it. This is quite annoying obviously, but the consequences of forgetting to do it are very bad. You can potentially lose all your work since the last check in. For other windows users I am not as sure that it would be such a problem, but it could be, especially since it only requires one locked file to break the entire checkout.

[Kuno Meyer (kuno-meyer)]

The same applies if a file that should be modified has read-only attribute (at least on "bzr 0.14")

This situation potentially occurs if you use bzr as "personal version control" of a working tree that is managed by another VCS (like SourceSafe/Visual Studio Team System).

The error messages while failing the pull operation are very inspecific in what caused the error.

[Alexander Belchenko (bialix)]

bzr should dealing with read-only attribute correctly. Perhaps by removing this attribute before changing file and then set it again?

[Kuno Meyer (kuno-meyer)]

Removing the read-only attribute before bzr operates does help in this case. But if you forget to do this, then bzr will leave your working copy potentially in an unconsistent (or at least difficult to rolling back) state. This behaviour is not what one one expects of a version control system.

bzr should handle such conditions more cracefully. I've listed below three alternatives how to do this; but in the context of this bug, variant b) is assumably be the apropriate one.

a) warning, before anything will be performed, or
b) atomic/transactional operation: if "pull" fails, everything will be rolled back (including restoring your uncommitted changes), or
c) treat permission flag changes as any other file content changes

-----

The following Windows batch script can be used to reproduce the behaviour:

bzr init b1
echo a > b1\a
bzr add b1
bzr ci -m . b1

bzr branch b1 b2
echo b > b2\a
bzr ci -m . b2

attrib +r b1\a

cd b1
bzr pull ..\b2
cd ..

-----

Resulting output:

bzr: ERROR: [Error 13] Access is denied: u'C:/TEMP/t1/b1/.bzr/checkout/limbo/new-1'
C:\Program Files\Bazaar\lib\library.zip\bzrlib\lockable_files.py:110: UserWarning: file group LockableFiles(<bzrlib.transport.local.LocalTransport url=file:///C:/TEMP/t1/
b1/.bzr/checkout/>) was not explicitly unlocked
C:\Program Files\Bazaar\lib\library.zip\bzrlib\lockable_files.py:110: UserWarning: file group LockableFiles(<bzrlib.transport.local.LocalTransport url=file:///C:/TEMP/t1/
b1/.bzr/branch/>) was not explicitly unlocked
C:\Program Files\Bazaar\lib\library.zip\bzrlib\lockable_files.py:110: UserWarning: file group LockableFiles(<bzrlib.transport.local.LocalTransport url=file:///C:/TEMP/t1/
b1/.bzr/repository/>) was not explicitly unlocked

[Aaron Bentley (abentley)]

Transforms with unexpected failures are now rolled back, so the impact of this problem is significantly reduced-- work will not be lost. I suggest reducing the priority of this bug to "medium".