Reverts all work unexpectedly (bzrsvn) when file locked

Bug #587300 reported by Mike Childs
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Bazaar
Confirmed
Medium
Unassigned

Bug Description

I have an xls file in my local bzr repository, along with all my source code. My local repo originates from an SVN repository that I get updates from and commit to every few hours or days.

When I bind to the SVN repository and update using "bzr bind" and "bzr update", I need to make sure that the xls file is not open in Excel 2007 because if it is open (and thus locked), when I run "bzr update" all my source code will be reverted and I'll lose all my changes in every file.

I'm using Windows XP. Here is the error:

bzr ERROR: [Error 32] The process cannot access the file because it is being used by another process
---
The behavior I expect when using 'bzr bind', 'bzr update' is as follows.

If I have a local repo (initially checked out from an SVN repo) at rev 200 with:
sourcefile.py, requirements.xls

and I've changed both since the last SVN update, I expect that the contents of both will be merged with the SVN repository when I bind/update:

file1 (local) <- merges into <- file1 (remote)

This is the usual behavior I've seen with bzr when the file is not locked, which works very nicely. This is also where I'll find conflicts that I have to resolve.

However, when requirements.xls is open in Excel (and thus locked by the system), when I bind/update, the error is displayed and a merge does not occur, rather a complete overwrite of the local copy occurs-so that I lose all local work because the remote files replace everything.

Revision history for this message
Parth Malwankar (parthm) wrote :

Hi Mike,

The expected behavior of bzr update is that it changes the working copy to be in sync with the latest (or the specified revision). The error message is merely bzr telling you that the OS (WinXP) has denied bzr access to the file as MSOffice has locked the file.
Could you specify what is the behavior you expect?

Changed in bzr:
status: New → Incomplete
Mike Childs (m-chi919)
description: updated
Parth Malwankar (parthm)
Changed in bzr:
status: Incomplete → New
Revision history for this message
Robert Collins (lifeless) wrote :

So, when a file is locked, update or tree transform is going badly wrong, and its not throwing an error.

To reproduce in a dev environment, I suspect taking out an exclusive file lock won't be enough on linux, as the file may still be movable and deletable. I'd consider adding some code to transform to simulate, or getting a windows using developer to reproduce and see whats up.

Changed in bzr:
status: New → Confirmed
importance: Undecided → Medium
Revision history for this message
Robert Collins (lifeless) wrote :

Possibly this should be high as its kindof dataloss (though perhaps your files are backed up by bzr in .filename#1 or similar - I forget our exact pattern. Please have a look.

Jelmer Vernooij (jelmer)
tags: added: data-integrity win32
Jelmer Vernooij (jelmer)
tags: added: check-for-breezy
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.