Bazaar

HPSS cannot rename-over packs on win32

Bug #376895 reported by Adrian Wilkins
48
This bug affects 10 people
Affects Status Importance Assigned to Milestone
Bazaar
Confirmed
High
Unassigned
Breezy
Triaged
Medium
Unassigned

Bug Description

Windows does not allow you to rename files over other files, but the finish() method of bzrlib.repofmt.NewPack tries this.

This causes a problem where a repository can get wedged (for a particular branch) ; if a failure leaves a particular pack in the packs folder, that pack cannot subsequently be written.

A case where this occurred was a push to a win32 server running bzr as an ISAPI extension under IIS. An (as yet undiagnosed problem) occurred and a particular pack was left in /packs. This pack was subsequently created again by a second attempt to push, creating a pack with the same MD5 which then could not be renamed over the original file.

Tags: win32
Revision history for this message
Robert Collins (lifeless) wrote :

One fix would be to just use the fancy rename. Other would be to improve the collision checking logic.

Changed in bzr:
importance: Undecided → High
status: New → Confirmed
Jelmer Vernooij (jelmer)
tags: added: win32
Revision history for this message
Glyph Lefkowitz (glyph) wrote :

By "the fancy rename", do you mean the MOVEFILE_REPLACE_EXISTING flag to http://msdn.microsoft.com/en-us/library/aa365241(v=vs.85).aspx ? That's probably the only "right" way to do that, but it requires >= vista.

Revision history for this message
Prasad H L Bhat (hlprasu) wrote :

Any work-around from user's perspective would be helpful here till this gets resolved in the code...

Thanks.

Revision history for this message
Adrian Wilkins (adrian-wilkins) wrote :

Glyph ; I think the "fancy rename" refers to the AtomicFile class in the bzr library

HL ; since this occurs only when a push fails, you should be able to move the offending pack out of the way and push again from the same branch. As long as the reason for the push failing was transient, this should correct the problem.

A less fraught but more long winded way of fixing this would be to move the wedged repository, then clone all it's branches into a fresh one in the old location.

A repack might fix this - but since the "wedge" pack might not be in the index, it might not be removed to obsolete_packs during a pack operation. (Should repacks just move ALL unknown packs into obsolete_packs?)

Jelmer Vernooij (jelmer)
tags: added: check-for-breezy
Jelmer Vernooij (jelmer)
tags: removed: check-for-breezy
Changed in brz:
status: New → Triaged
importance: Undecided → Medium
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Subscribing...

Other bug subscribers

Remote bug watches

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