[ale] inode change after vi a file ?

[Jerry Yu]

I guess ":set backupcopy=yes" should be the default. Otherwise, the inode
change would make it hard, if not impossible, for forensic or audit folks to
use information on these vi-touched-file in court. From where I see it,
after the inode change, for all purposes, they have nothing to do with the
original files.


On 3/31/06, fletch at phydeaux.org <fletch at phydeaux.org> wrote:
>
>
>
> > 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
>
>
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://www.ale.org/mailman/listinfo/ale
>
-------------- next part --------------
An HTML attachment was scrubbed...