refactoring and noting mv/rename after the fact

[John Yates]

On Monday, April 11, 2005, Aaron Bentley wrote:

> Ultimately,
> rename(2)s don't always mean what they look like (because they're used
> to atomically update files and such), so monitoring rename(2) wouldn't
> be any help.

Not to throw cold water on the notion of monitoring operations but to the
extent that bzr aspires to control more than just text files maintained
with simple Unix tools monitoring as I understand it is likely to find it
"rough sledding".

As part of a project some years ago that tried to recover subjective user
actions from operations on a Windows file system.  Doing that was quite a
challenge.  Just understand that a single file had been edited and that
a new version had been created was daunting.  The MS Office Big 3 each
follow a different paradigm to perform a reliable update.  These vary from
MS Office release to release.  Here is what we found for the most recent
release at that time (circa 2001):

MS Word:
  create <temp>
  write new contents to <temp>
  delete <document>
  create <document>
  write new contents to <document>
  delete <temp>

MS Excel:
  create <temp>
  write new contents to <temp>
  delete <document>
  rename <temp> to <document>

MS PowerPoint:
  create <temp>
  write new contents to <temp>
  overwrite <document> with new contents
  delete <temp>

Notice that in each case, once the operation is complete the file system
contains a file named <document> and the failsafe <temp> is gone.  In the
first two cases <document> refers to a new inode.  

I will spare you the gory details of application level locking, saying
only that PowerPoint and Excel write lock ownership information directly
into a header at the front of <document> while Word writes effectively
the same information to a distinct file in the same directory.

/john