Re: Dar slice numbering

Thomas Jacob <[email protected]> Thu, 04 Jan 2007 11:51:27 +0100
Newsgroups gmane.comp.sysutils.backup.dar.general
Message-ID <1167907887.4855.25.camel@enterprise>
Just to add my thoughts on this, I think it's not
a good idea to simply turn dar slice numbers into fixed 4 
digit strings, as this could possibly break any number of
old scripts that assume otherwise. 

If this implemented at all then please please as an optional extra,
possibly
by allowing the user the specify a complete alternate format
string for generating the filenames ("something%02d.mydar" with
"<BASENAME>.%d.dar" remaining the default as it is).

That being said I would question the need for this in principle,
if you have so many slice numbers to make you lose track of
them you probably are using scripts to handle your backups
already, so beefing up your script logic should be the way to
go, instead of expecting dar to do another little thing that
could easily be handled in a script. 

So a more useful addition would be maybe be an option
that makes dar prints out the last slice number. 

But then again, different people, different requirements ;)

On Mon, 2006-12-25 at 12:11 -0500, T wrote:
> On Sun, 24 Dec 2006 21:30:29 +0100, Wiebe Cazemier wrote:
> 
> > Coincidently, I just field a feature request for this at the tracker:
> > 
> > http://sourceforge.net/tracker/index.php?func=detail&aid=1619638&group_id=65612&atid=511615
> > 
> > Summarized, I suggested either an option to set the number of digits, or just
> > use four. 9999 slices should be enough for everybody, and I don't think having
> > slices like 0001 is ugly. Blender, for instance, uses this for it's
> > framenumbering, and it's very clean in my opinion. 
> 
> I've been using dar for over 3 years. This is actually the 1st time that I
> post to this mlist to discuss the problem that has bugged me for over 3
> years. I guess it is an issue for most dar users, even though they have
> not speak up. 
> 
> Personally, I think Wiebe's suggestion does make sense. It is a good
> compromise to both side.
> 
> > I know that in theory you
> > can surpass it, but is that really a problem? No one is going to make a backup
> > of 10.000 slices.
> 
> Some might exceed it, but it might only be 0.001 of a chance. Still they
> have 2 choices: 
> 
> - live with it, as they are living with current dar
> - or increase the per slice size.
> 
> I second to Wiebe's proposal.
> 
--

Thomas Jacob
-Softwareentwickler-
_______________________________
IMS Internet-Media-Service GmbH
Bayrische Str. 18
D-01069 Dresden

Fon: +49 (0)351 2 11 20 33
Fax: +49 (0)351 2 11 20 20

[email protected]
http://www.internet24.de

Prickle-Prickle
4th of Chaos, 3173

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

_______________________________________________
Dar-discussions mailing list
Dar-discussions-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/dar-discussions
signature.asc (application/pgp-signature, 191 B)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQBFnNwvgF9cFv867HwRArHQAJ9zBj1rtzMN77wNWDIc7Vakgy5B8gCgsyaK
EQddCgZ3b78rWWGJjVwh2TA=
=+kzn
-----END PGP SIGNATURE-----