Re: dealing with timestamp (in-)accuracy

Lasse Kliemann <[email protected]> wrote:


> In the other message I wrote about problems with 'rapid' dumps, by which =
I =

> mean a sequence of dumps and small filesystem modifications that happen =

> directly after each other. For instance, touch a random file in the =

> filesystem, do a dump, then touch another random file, do a dump with a =

> higher level, etc. Doing that I get strange results like files missing fr=
om =

> incremental restores and warning messages 'No new inode number for'.

Well, I see that the probability for your problem is low with real world du=
mps
but it is > 0. A 100% clean way would be to sleep(1) before starting the du=
mp
and then use >=3D instead of >. If I omit the sleep(1), I may get some files
onmore than on dump although it did only change once.

J=F6rg

-- =

 EMail:[email protected] (home) J=F6rg Schilling D-13353 Be=
rlin
       [email protected]                (uni)  =

       [email protected]     (work) Blog: http://schily.blogspo=
t.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/sch=
ily