Rogério Brito said on Wed, Jul 04, 2007 at 06:26:37AM +0000: > Not only that, but some of the files on the afio archives were > compressed, while others were not.
True. > I think that the overhead for > compressing all files (and not choosing which one should and which one > shouldn' t) would be negligible and would potentially make the backups > smaller (and faster, but I don't know how much of the time is spent > choosing which files are or which files aren't going to be > compressed). I think there could be a big change. Why compressing already compressed formats ? Especially when you use bzip2 which is quite slow. > I guess that the criterium is that files smaller than a frame/page > aren't compressed, is that right? No. Criteria is a set of file extensions (it's documnted in afio man page, and mondo adds some other extensions to the list. I plan to re-work that anyway for 3.0.x as there are some bugs in that part). > >First this is an upstream problem, not a Debian one IMO. > > Not to sound harsh here, but the maintainers are the interface between > the users and upstream. That's because we have wishlist bugs and the > ability to forward the bugs to upstream in Debian's BTS. Again, this > isn't meant to sound harsh. Ok. I don't know obviously the Debian process tat well ;-) But what I think should be done in such a case is open a bug in our trac system so that it can be discussed upstream, with a link in the BTS no ? > I think that an option to do what I ask wouln't hurt. After all, I > take backups every single day in ISO images (since the other bug that > I filed for mondo to call cdrecord with the -dao option is > approximately 1 year and a half without action) and burn them on CD > and verify the MD5 sums with either readom (from the cdrkit package) > or with dvdisaster. I'm working on separating all those parmeters (_dao and the like) from the code and put them in config files. It takes time, and it's only for v3.0.x. As I have focussed up to June on 2.2.x, it ddn't progress a lot. I just began during my vacations to work again on 3.0.x. Hop to propose a version by September for testers. On the problem in itself, CD/DVD damage during time. You may have them corect in MD5SUM at the time you burn it and incorrect 2 years later. That's where the "feature" would play nicely ;-) > >What we could do is rename the files to make them not having the suffix. > >But that should be an upstream enhancement request IMO. > > At least, this would be a step on the right direction, since the way > it is, it is misleading. Ok. Would you like to fill a bug upstream ? Greetings, Bruno. -- Linux Profession Lead EMEA / Open Source Evangelist \ HP C&I EMEA IET http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org
