Re: Perfomance problem backupscript (more details and tests)

Hi,

> > How is the 64 bit problem with NT to be solved ?
> > By a giant persistent translation table ? 
> > The temptation to stretch the rules is substantial for
> > implementors of innovative fileystems.
> 
> The way I did derscribe it with my last mail: POSIX.1-2001 allows basic 
> cardinal OS types to be wider than sizeof(long). Former Cygwin versions
> did hash NT file serial numbers to 32 bit and failed (and so did mkisofs
> with trying to find hard links) and newer ones (since abut a year) just
> use 64 bits.

Yes. But if i would strive for NT filesystem access from
a 32-bit OS where ino_t happens to be 32-bit ...
... you see the temptation to stretch POSIX to the max
in order to achieve a bearable solution ?

If there is no clear statement that protects our expectations
towards a decent File Serial Number then we have to expect to
be faced with such overstretched implementations.

My currently best link about POSIX and inode numbers is :
http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap03.html#tag_03_175


> Not in case that the filesystem follows POSIX correctly.
> 
> Well: I encourage you to send a bug report to the maintainers
> of the filesystems that behave incorrect.
> > No bug, but feature. It [ReiserFS] complies to POSIX man rename(2).
> 
> So it _does_ update ctime on rename(2)?
> 
> Note that POSIX _requires_ ctime to be updated on a rename.

No, it doesn't.

It _requires_ the parent directory's timestamps to be updated
but _allows_ the renamed file's ctime to remain old.
man rename(2) of IEEE Std 1003.1 is so friendly to state
this ambiguity explicitely.

Most official link i found :
http://www.opengroup.org/onlinepubs/009695399/functions/rename.html
" APPLICATION USAGE

 Some implementations mark for update the st_ctime field of renamed
 files and some do not. Applications which make use of the st_ctime
 field may behave differently with respect to renamed files unless
 they are designed to allow for either behavior."


> I am no longer sure what traget issue you have with this
> discussion...

Among other things, it is to learn from you what you know
about inodes, timestamps, incremental backup, etc.
Thanks for several valuable hints.
If you ever read the _decisive_ sentence about file serial
number lifetime persistence then do not hesitate to tell
me. (Despite my reluctance i would love to trust it.)

In reply i was able to point you to a possible disappointment
of users who might have a hard time picking a single renamed
file out of a multi-level star backup.

The reason why i started to participate in this thread was
to contradict the statement of Les that there was no
alternative to incremental concepts which rely on single-file
ctime update on rename.
Two independent counterexamples have been discussed now :
- star, which does not need that ctime update if a single, whole
  filesystem is backuped - and if it is restored as a whole.
- my own concept which i developed from intrusion detection
  ideas.

During the discussion i mistrusted two assumptions :

- The accuracy of ctime of renamed files.
  This is a practical and widespread problem and there is no
  hope that POSIX will help us to enforce the assumption in future.

- Persistence of inode and device numbers.
  This is a theoretical fear. I did not encounter problems yet.
  Nevertheless i still got no confirmation that the contrary
  is indeed clearly demanded by POSIX. (Pity.)


Have a nice day :)

Thomas