last archive slice

Hi Denis,

In dar version 2.1.3, libdar mistakes the last slice number sometimes.

For example, create an archive with slice sizes of 3 MB. Say this results 
in 6 slices. Now create the archive, same basename, same directory, and 
allow the library to overwrite the existing archive, but use 5 MB slices.
Suppose it results in 3 slices.

Now try to list the archive. I get the following user interaction question:

"/opt/user/backups/dar_backups/test6.6.dar is a file from another set of 
backup file, please provide the correct file."

Then the user has to delete slices, one by one starting with the highest 
number, and retry the list command until it works.

Is this the expected behaviour? Shouldn't libdar see that the third slice, 
in this example, would be the last archive slice? I have to admit, it's 
confusing for a user who does this to know that the archive consists of 
only three slices when six are on disk.

You wouldn't have to change the slice size to get this problem. Suppose you 
did a full backup and got 12 CD-R-sized slices. Then during the course of 
the following week, you delete a bunch of directories that you don't need 
anymore, and do a full backup which has 11 CD-R-sized slices. Dar will 
miss the fact that the last slice  #11, but will still ask the user for 
the 12th slice.

I see the following solutions:

1) libdar deletes all slices on a disk if they have the same storage 
directory and basename as the new one being created. It might do this 
before creating the archive, or after creating the archive. Perhaps doing 
this after will be more efficient, since you only delete slices that 
haven't been overwritten, if there are any.

2) The search algorithm gets fixed to stop on the first slice with a "T" 
type terminating character in the header. Am I correct in interpreting the 
"T" to mean that the slice is the last one in the archive? I assume that 
libdar figures out the last slice by relying on the filename, not the 
header, although I haven't checked the sourcecode.

3) A combination of 1) and 2).

I see a similar problem when creating archives with KDar. I have a progress 
bar that periodically updates which slice is currently being written, and 
what that slice's size is. When the "pause" between slices option is 
chosen, and libdar asks if it okay to continue writing the next slice, 
first it writes the "non-terminating" character to the slice header, and 
then waits for the user to answer the question. In the case where the user 
is overwriting an older archive, the statusbar code runs through the files 
on disk until it finds the one with the "T" in the header. This will be 
the last one in the older archive, and the statusbar will jump to that 
slice instead of the current one. 

Perhaps libdar should write the "N" to the termination type only if the 
user says it's okay to continue, and write an "I" to the termination type 
if the user cancels. That way we know that the "last" archive slice is 
actually invalid, i.e. the creation process was aborted, or failed in some 
way.

For the status indicator, the best solution would be for libdar to have a 
"currentSlice" method, which could be called at any time to determine the 
slice number of the current one being written or read.

Should I file a bug report for any of this?

Cheers,
JB

-- 
Johnathan K. Burchill, Ph.D.
[email protected]

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

iD8DBQBBAvbOrXMSOtiWrO4RAr59AJ93TYxhhH2JAGPfbqVbG0rMZDdS9gCeJLKy
ANQYlh55b8/ubjQIn0dcT1g=
=rmx/
-----END PGP SIGNATURE-----