<div class="gmail_quote">On Tue, Nov 2, 2010 at 2:01 AM, Vincent Ladeuil <<a href="mailto:v.ladeuil%2Blp@free.fr">v.ladeuil+lp@free.fr</a>> wrote: <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> All crash reports leading to empty pack files, we are aware of so far, were due to the file system lying to us pretending that both file contents and the file metada have been written to disk. What you've seen occurs when the file contents are *not* written to disk even when moving these files from one directory (.bzr/repository/upload) to another (.bzr/repository/packs or .bzr/repository/indices) have been succesfully recorded. But bzr rename these files only *after* writing them, flushing them and closing them. It will help if you could file abug explaining what kind of crash you experimented, which OS and which file system you are using so we can collect more info on the contexts where this bug manifests itself. I have a repair-repo script that automate part of the repairing that I should submit (based on the one you found in the bug report), but this address only the repository part of the problem, not the branch repairing step. Vincent </blockquote><div> Still digging out from travel, but this thread got my attention. FWIW, I tried to break bzr branches on Windows as part of our acceptance testing. I did things like kill bzr, yank power cords and yank network cables during large (few hundred MB, few thousand files) 'bzr commit' operations, followed by 'bzr check'. I was not especially systematic. I just tried to simulate some things that really happen to us. (We have violent weather in the summer.) In every case so far, everything is fine according to 'bzr check'. The worst thing I've had to do is 'bzr break-lock'. Actually, I should file a feature request: it might be nice if 'bzr check' reported stale locks. I have not repeated this Windows-only testing on Linux. So I don't know anything about John S's comment about calling sync on directories whose catalogs are changed by a content rename. ~M </div> </div>