Re: last archive slice

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Johnathan Burchill wrote:
| Hi Denis,

Hello Johnathan,

|
| 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?

yes.

| 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.

This is a user mistake to hide under the same basename in the same
directory slices of different archives.

There is no use to keep last slices of an old archive, it only waste
your disk space: If you miss the first slice, you won't be able to
restore anything from your old archive. Else, if you definitively want
to keep several archives with the same name, it is not a very good idea
to mix their respective slices toghether in the same directory... ;-) no ?

|
| 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.

what would be the 12th slice useful for ? why would it have to stay on
disk for ?

|
| 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.

I do not agree. libdar deletes nothing. 'rm' command does. ('rm' or
unlink() system call)

|
| 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.

Assuming in libdar the mistakes of the users is not a good idea. I can
already hear some users complaining that libdar does not remove unuseful
slices of older archives, while it does not complain anymore that extra
slices exist and do only waste disk space.

I don't like MS-office like programs that tend to have the prentention
to be more clever than their users. They either get much restrictive and
blindly forbid operation needed by more clever users than the program
developers, or automatically do stupid things or have stupid questions
to the user, that even less clever users find borring.

|
| 3) A combination of 1) and 2).

no again. If a user wants to clean its previous archive it is simple:

~  rm old_archive.*.dar
~  dar -c old_arhive ...

nothing more nothing less. Simple, everybody understands, no hidden
features from dar or libdar, no hidden surprises. (lib)dar is only a
backup software.

|
| 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.

To my point of view, this is here again a user mistake. Once you
overwrite the first slice of the old archive, all the other slices of
this archives are useless. Why not removing first all the slices of the
old archive you have planned to overwrite ?

|
| 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.

perhaps, KDAR could propose a "remove old archive slice" option ? ;-)
option, that can simply rely on the rm command or unlink system call...

|
| 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.

a new callback function ? ;-)

|
| Should I file a bug report for any of this?

I don't think so, do you still ?

|
| Cheers,
| JB
|


Cheers,
Denis.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFBA0OvpC5CI8gYGlIRAhTVAKC2e5HBV+gf0a7r/13u/5kdu+sTRQCePg08
y3Ne+36JhvyFZdVrkv2KncA=
=3y7l
-----END PGP SIGNATURE-----



-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click