Re: [Bug-tar] Incremental restore seems to first create then rename

[Joerg Schilling]

"Felix E. Klee" <address@hidden> wrote:

> On Sun, 12 Sep 2004 21:29:03 +0200 Joerg Schilling wrote:
> > Check 'star' ftp://ftp.berlios.de/pub/star/alpha/
> > 
> > star-1.5a47 introduced a incremental restore that just does what you
> > like...
>
> I already considered that tool. Today, I tried it out, and it handles
> the test cases I originally threw at GNU tar flawlessly. What I haven't
> tested yet, is pattern matching. Hopefully, this allows me to include
> only parts of the directory tree when doing dumps (I don't want to back
> up temporary directories, etc.). Anyways, at first sight, star looks
> like a very powerful TAR implementation.

The current star behavior is to set the POSIX.1-2001 keyword

SCHILY.volhdr.dumptype=

to the following values:

No level= option                --undefined-- 
with level= option no restrict. SCHILY.volhdr.dumptype=full
level= option but restrict.     SCHILY.volhdr.dumptype=partial

A restriction may be anything that may tells star not to archive
all files and should result in a SCHILY.volhdr.dumptype=partial
header (I am not sure that this is already handled correctly).

The file /etc/tardumps is only written if there is a
SCHILY.volhdr.dumptype=full header _and_ no error did ocur.
Errors may already be suppressed using the errctl=name option.

Let us discuss the constraints......

If I would not have the SCHILY.volhdr.dumptype= keyword, I could
not know whether the dump is complete and is expected to allow
correct behavior in any case. Users would complain about "bugs"
in star but the problems would rather be caused by incorrect usage
of star.

I could add a new _restore_ option that tells star to ignore the 
SCHILY.volhdr.dumptype= keyword and do the best job that is possible
with the given data. If I would do this, then star needs to be able
to know the last dump date in _dump_ mode. As star currently does
not write /etc/tardumps if the dumptype is not "full", I would also 
modify star's _dump_ behavior.

If I would allow star to write /etc/tardumps in partial dump mode, 
this would cause star to missbehave in case someone likes to do mixed
full/partial incrementals. A "full" incremental should always be done
relative to the last "full" incremental time stamp. A "partial"
incremental should always be done relative to the last "partial" incremental.

Another problem is that it would go far bejond usability if star would
try to archive all options that are causing a dump to become "partial".
If a user changes the "restricting" options between "partial" incrementals
he should at least know that the results will be complwetely unpredictable.

What I could do is to change the /etc/tardumps format from:

/mnt                                      0 1094499417.450458 Mon Sep  6 
21:36:57 2004
/mnt                                      1 1094499441.958995 Mon Sep  6 
21:37:21 2004

to:

/mnt                                      0F 1094380222.398395 Sun Sep  5 
12:30:22 2004
/mnt                                      1F 1094380240.235921 Sun Sep  5 
12:30:40 2004
/mnt                                      0P 1094499417.450458 Mon Sep  6 
21:36:57 2004
/mnt                                      1P 1094499441.958995 Mon Sep  6 
21:37:21 2004

and add a new _restore_ option like -partial-restore

Let us continue the discussion int the star-developers mailing list.

Jörg

-- 
 EMail:address@hidden (home) Jörg Schilling D-13353 Berlin
       address@hidden           (uni)  If you don't have iso-8859-1
       address@hidden   (work) chars I am J"org Schilling
 URL:  http://www.fokus.fraunhofer.de/usr/schilling 
ftp://ftp.berlios.de/pub/schily