Re: dealing with timestamp (in-)accuracy

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


--ILuaRSyQpoVaJ1HG
Content-Type: multipart/mixed; boundary="5gxpn/Q6ypwruk0T"
Content-Disposition: inline


--5gxpn/Q6ypwruk0T
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

* Message by -Joerg Schilling- from Tue 2008-03-11:
> Lasse Kliemann <[email protected]> wrote:
>=20
> > In create.c of star-1.5a87, line 281, it reads:
> >
> >    } 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);
> >       }
> >
> > 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=
 it is=20
> > already included in a previous dump (and hence will not be included aga=
in). I=20
> > wonder whether the checks shouldn't be for greater *or* *equal*, i.e.:
> >
> >       if (info->f_mtime >=3D Newer.tv_sec) {
> >          /* EMPTY */
> >          ;
> >       } else if (info->f_ctime >=3D Newer.tv_sec) {
>=20
> This is not really correct as it could result in duplicate files in succe=
ssive
> incrementals.
=20
Yes. I wonder whether this is a problem. This could happen anyway when usin=
g=20
filesystem snapshots with the recommended procedure: 1) take a timestamp, 2=
)=20
take the snapshot, 3) do a dump with dumpdate=3Dtimestamp.

> Did you actually see missing files in incrementals?

Yes. Please try the attached script. It will report FAIL with, I guess, 95%=
=20
probability, meaning that the file called `1' is not included in the level=
=20
one dump. When you insert a sleep statement at the place marked HERE, the=
=20
error probability decreases. With 1 second of sleep, I could not provoke an=
=20
error. With 0.9 seconds, it still might happen.

It does not help to put sleep or sync statements between the touch statemen=
t=20
and the dump.

Lasse

--5gxpn/Q6ypwruk0T
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=rapid

#!/bin/sh

rm -fr src &&
mkdir src &&
rm tardumps &&
for i in 0 1; do
{
	(cd src && touch "${i?}") &&
	star -c -acl -link-dirs -xdev level="${i?}" f=dump"${i?}".tar \
		-wtardumps tardumps=`pwd`/tardumps -C `pwd`/src .
	# HERE
} || exit "$?"
done &&
if star t f=dump1.tar | grep '^1'; then
	echo OK
else
	echo FAIL
	exit 1
fi

--5gxpn/Q6ypwruk0T--

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

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

iQIcBAEBAgAGBQJH1qNcAAoJEFYll6N4nhdvkQgP/jbK+2sYHTt/2ekE6k+5VfAt
Uykitw3kxxEI2XcfchWbKbpAL0FZHI4jyYFdo789OE98kLGI8H6uqEBxuNvL96eO
OcUl9FbkWOHjOYt/LoZCGzAjtl6MQ4Mhkmbe2baAQ+JVIth+gvgbGTIUAHUaHL3S
uOfnE/S57XLMu3RhHBg4sAgvvjg7f4QpSCIJ+5ZtvU8oDHSy3BvRcbRC5h7+F+un
YLqG+/K5B7M5JHg3+YliOFWqHb4bRJddTRBQ7DvRVHJzXVFwmRSpYAd2HsX1qx82
dsOnyP3C9cTgbYPKyIBZmAd4wJdQId5WSq4t1AbEtPTU8b+PgtUDJLoVQRc35pe/
av8wa2F9Myji+o6w9jJPNp1Zsm9EbLk0qzareLXjQnwo1a2TVD9iO6aK3BPTWtuC
HPUB8LAQlKYqY6nVb5XHcjEVZ8iz8pdxhl+mHPQ4/4sPD86aU0X9SDbDcXldwt5j
rPYOEpp8U4Dx8ev4prkVc9H6i6eR3tVXkjym/EtNswMR71C4aHHdJE8rtvyX3G4G
e4N4qA4fKR2iylreswOOx+YS9doJB0YoPkq/9hF073m7o2stVXiV2mdrD967McKO
PaVz5suhZm+H0KWbLINjjV3MDr+BnbaW6WVJDgDs8PHAiu69TvFMLWlsLrKEiy5e
G3i5imSgReSg4Ff9SJ3c
=s4CZ
-----END PGP SIGNATURE-----

--ILuaRSyQpoVaJ1HG--

--===============1277350989==
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

--===============1277350989==--