[ale] inode change after vi a file ?

[fletch at phydeaux.org]

> I don't understand though why people are saying that cycling inodes is a
> good thing?  I thought one inode per file so it was the number of total
> files and directories that really mattered.  If you had too many then you
> had problems.  Is there some reason to reassign inodes?  Thanks,

The reason it's getting a new inode number is because it's a different,
new file.  You're not in anyway guaranteed that any sets of write()
syscalls will be atomic, save by using some locking protocol.  The problem
is that things like flock() are notoriously flakey when considering things
like NFS, not to mention worthless unless every single thing accessing the
file honours whatever locking/exclusionary protocol (flock(), making a
lockfile, making a lock directory (which can be slightly more robust over
NFS because mkdir() is guaranteed to be atomic even there), ...).  A
rename() system call is guaranteed to be atomic, even over NFS.

It's not that vim's intentionally trying to shuffle around inodes, it's
that it's using the lowest common denominator to ensure that its not going
to intersperse its results with another process' when it does save.

-- 
Fletch                | "If you find my answers frightening,       __`'/|
fletch at phydeaux.org|  Vincent, you should cease askin'          \ o.O'
                      |  scary questions." -- Jules                =(___)=
                      |                                               U