Re: Re: Perfomance problem backupscript (more details and tests)

Les Mikesell <[email protected]> wrote:

> On Thu, 2005-10-06 at 15:48, [email protected] wrote:
>
> > The man page of stat says nothing about persistence of
> > inode numbers.
>
> At the time that was written, inode numbers were physical
> things in the filesystem - and in fact real inode numbers
> still are.  If the things on your filesystem don't persist,
> you don't have much to back up.  The problem is that people
> want to pretend that certain filesystems are unix-like when
> they aren't, so stat() claims something is an inode number
> that isn't.

stat() _needs_ to return an inode number, otherwise it is not POSIX
compliant.

If a filesystem definition itself does not include "file serial numbers",
the file system driver implemenation needs to implement them.....


> At the time the ctime specification was written, there was
> no way to rename a file or modify any attribute that needed
> to be saved without modifying the inode.  This was not
> an accident, and observing ctime changes was the designed-in
> way to detect files that needed to be copied in incremental
> backups.  Blame whoever you want for not maintaining that
> mechanism in not-quite-unix-like systems today, but when
> gnutar first used ctime it was a reliable mechanism.

POSIX is unambiguous here:

Upon successful completion, rename() shall mark for update the st_ctime and 
st_mtime fields of the parent directory of each file.

This means: any implementation that does not update st_ctime on
a successful rename() is broken.


Jörg

-- 
 EMail:[email protected] (home) Jörg Schilling D-13353 Berlin
       [email protected]		(uni)  
       [email protected]	(work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily