Re: dealing with timestamp (in-)accuracy

--===============0024950124==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="lLR1BQqf7txDtYcF"
Content-Disposition: inline


--lLR1BQqf7txDtYcF
Content-Type: multipart/mixed; boundary="95CBLwa+io9O2zXc"
Content-Disposition: inline


--95CBLwa+io9O2zXc
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

* Message by -Lasse Kliemann- from Thu 2008-03-06:
> In create.c of star-1.5a87, line 281, it reads:
>=20
>    } else if (dumplevel > 0) {
>       if (info->f_mtime > Newer.tv_sec) {
>          /* EMPTY */
>          ;
>       } else if (info->f_ctime > Newer.tv_sec) {
>          if (dumpmeta)
>             info->f_xftype =3D XT_META;
>       } else {
>          return (FALSE);
>       }
>=20
> As far as I can see, this is the place where it is decided upon whether a=
=20
> file will be included in the current dump, or if it may be assumed that i=
t is=20
> already included in a previous dump (and hence will not be included again=
). I=20
> wonder whether the checks shouldn't be for greater *or* *equal*, i.e.:
>=20
>       if (info->f_mtime >=3D Newer.tv_sec) {
>          /* EMPTY */
>          ;
>       } else if (info->f_ctime >=3D Newer.tv_sec) {
=20
(...)=20
> Further down, it reads:
>=20
>    } else if (Newer.tv_sec && (Ctime ? info->f_ctime:info->f_mtime) <=3D
>                         Newer.tv_sec) {
>=20
> Maybe it should be '>' here, i.e.:
>=20
>    } else if (Newer.tv_sec && (Ctime ? info->f_ctime:info->f_mtime) >
>                         Newer.tv_sec) {
>=20
> but I am not so sure about that (since I am not sure what this statement =
is=20
> for).

In the other message I wrote about problems with 'rapid' dumps, by which I=
=20
mean a sequence of dumps and small filesystem modifications that happen=20
directly after each other. For instance, touch a random file in the=20
filesystem, do a dump, then touch another random file, do a dump with a=20
higher level, etc. Doing that I get strange results like files missing from=
=20
incremental restores and warning messages 'No new inode number for'.

This goes away if I insert 'sleep 1' *after* the dump, or if the=20
modifications suggested above are made. I have a patch attached; but I do n=
ot
know whether this really is the correct way to deal with it. (There are thr=
ee=20
modifications in the patch, and it seems that only the first two of them ar=
e=20
necessary to make the problem go away in my tests.)

Lasse

--95CBLwa+io9O2zXc
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="create.c.diff"
Content-Transfer-Encoding: quoted-printable

--- create.c.orig	2008-03-09 22:16:34.000000000 +0100
+++ create.c	2008-03-09 22:17:41.000000000 +0100
@@ -279,17 +279,17 @@
 	} else if (maxsize && info->f_size > maxsize) {
 		return (FALSE);
 	} else if (dumplevel > 0) {
-		if (info->f_mtime > Newer.tv_sec) {
+		if (info->f_mtime >=3D Newer.tv_sec) {
 			/* EMPTY */
 			;
-		} else if (info->f_ctime > Newer.tv_sec) {
+		} else if (info->f_ctime >=3D Newer.tv_sec) {
 			if (dumpmeta)
 				info->f_xftype =3D XT_META;
 		} else {
 			return (FALSE);
 		}
=20
-	} else if (Newer.tv_sec && (Ctime ? info->f_ctime:info->f_mtime) <=3D
+	} else if (Newer.tv_sec && (Ctime ? info->f_ctime:info->f_mtime) <
 								Newer.tv_sec) {
 		/*
 		 * XXX nsec beachten wenn im Archiv!

--95CBLwa+io9O2zXc--

--lLR1BQqf7txDtYcF
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)

iQIcBAEBAgAGBQJH1G23AAoJEFYll6N4nhdvVb4P/0K+OXvJBAWJmxPWxih4WgAc
otybitPoKMyCS+pwAy7viKTuArtgcx8BMJPsnwvSeUAzALUQxcIfKUBte7hh1KMr
f1An4wJNbrQ0GXKSQkWzAHf7vM3b5zij79dsf8kiPV7X14rqk7Tq5Zxg8voHVlnO
uZ+L41LRQ6DhRVbuNPLMhhO8jChSYmTdJUzTrdvCdbxOOCI6PNirs72zwEBYmhlT
gJusJ6DmXFNtmnxZAoImSWGqPbNURGgBbSUYxSKJg4/kRGf4G0wulhxyOcYeMsRQ
ykZMkLSoWstm7Q4GzKoCGkuOWQWV5AHmn+oFZo6B9DHsJaTKlhjlJWM8ZiBDid+n
nnZHS0VWkTJ1l2MxPRMWleEfWKgFpf8EBzIIlTDeKPNnlhejfa37bEBLOe2pxWJv
BTXUt4hks1rQS6C9n/aib6p3BhOOKk7P9aviz9Y3atRzMH6WmOxVUsBwQCpc2qye
xM782OZEPULX8NqyxygKGrmJnznUlLi0BksmjEx9fMXFZMReKqtuF4nfrTA+zWHR
Pn3HFmVALACB3ZGO3z0uzYQlWl9dXzhs5unshXOGqcY/A+UvNdXyG7eZZgxlPOQz
KsV5PZbZFB1f2Gc8gFkwp8suM6NbFIbgMxpHSXdSFeVNHjMp8hm5186DOawAoUav
2i77yOHFfqsIl0ySrXLH
=l+OB
-----END PGP SIGNATURE-----

--lLR1BQqf7txDtYcF--

--===============0024950124==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Star-users mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/star-users

--===============0024950124==--