Bug#565202: afio: Bug#565202: verification against filesystem does not work
Hi Jari, On Thu, 27 Jun 2013, jari.aa...@cante.net wrote: On 2013-06-26 21:28, Koen Holtman wrote: | | ..fix is now in github head | | https://github.com/kholtman/afio | | e2666357742046b3de7fef640f70a71a68636efb improve -r option, HISTFILE | update Pulled, will package shortly. I'm attaching the build log as well. We can ignore long long message, but see the other messages. I looked at the other messages, and they are not coding errors. The compiler is emitting warnings on the dup(), chown(), and nice() where it should not. This is caused by (in my opinion) a bug in the glibc header files. See https://github.com/kholtman/afio/issues/3 for the long version of the explanation. So overall the comple looks OK to me. Cheers, Koen. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#565202: afio: Re: Bug#565202: afio: verification against filesystem does not work
..fix is now in github head https://github.com/kholtman/afio e2666357742046b3de7fef640f70a71a68636efb improve -r option, HISTFILE update Cheers, Koen. On Mon, 17 Jun 2013, Koen Holtman wrote: Hi Jari, OK I will add a stat() and see if I can make some other improvements. May take me a few weeks to get around to it, as summer seems to have started here. Cheers, Koen. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#565202: afio: Re: Bug#565202: afio: verification against filesystem does not work
Hi Jari, OK I will add a stat() and see if I can make some other improvements. May take me a few weeks to get around to it, as summer seems to have started here. Cheers, Koen. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#310828: afio: pipes should be like real devices
Taking stock as the upstream maintainer: - This wishlist item has been open for 5+ years, nobody submitted a patch yet. - I have no plans to implement myself. Recommendation to Debian maintainer is to close this item as 'will not fix' or a code like that. Cheers, Koen. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686613: afio: fails with ASX no fsname for this name
Fixed it, the fix is in the github head. https://github.com/kholtman/afio Koen. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#310806: afio: enhanced pipe device command line patch
Patch is now incorporated (with some extensions) into upstream github repository. Cheers, Koen. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#578046: currupts archives on 64bit systems with buffers larger than 2gb
[removed some general mailing lists from cc:] Overall, I have concluded that correct support for =2GB afio memory buffers on 32 bit or 64 bit systems opens up a too-large can of testing worms, especially as size_t and int are still 32 bits even on amd64. So I have resolved this (in my upstream development copy) by making afio reject attempts to use buffers larger than 1.5GB. See the HISTORY file in the upstream repository https://github.com/kholtman/afio for the full details. At least this way there is low risk that afio will silently fail. Cheers, Koen. On Mon, 27 Feb 2012, Koen Holtman wrote: On Fri, 16 Apr 2010, Yuri D'Elia wrote: Package: afio Severity: important Tags: patch When the block size * block count equals to 2gb or more, afio corrupts the archive by truncating all files larger than 2gb. [...] Thanks for the bug report and patch, I am reviewing and incorporating it in the upstream. The patch upgrades some uints to size_t, but it does not upgrade the count argument of readall to size_t, so I think this might lead to the achive ending up corrupt because not all data is written into it if your memory buffer (size * block count) is over 4GB and the file being archived is over 4 GB. I am not entirely sure, I have not tested it to verify, but just a warning: if you upgraded to 4GB memory buffer you might have gotten corrupt archives. Cheers, Koen. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#578046: currupts archives on 64bit systems with buffers larger than 2gb
On Fri, 16 Apr 2010, Yuri D'Elia wrote: Package: afio Severity: important Tags: patch When the block size * block count equals to 2gb or more, afio corrupts the archive by truncating all files larger than 2gb. [...] Thanks for the bug report and patch, I am reviewing and incorporating it in the upstream. The patch upgrades some uints to size_t, but it does not upgrade the count argument of readall to size_t, so I think this might lead to the achive ending up corrupt because not all data is written into it if your memory buffer (size * block count) is over 4GB and the file being archived is over 4 GB. I am not entirely sure, I have not tested it to verify, but just a warning: if you upgraded to 4GB memory buffer you might have gotten corrupt archives. Cheers, Koen. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#509287: at least move to non-free
Speaking as the up-stream afio maintainer: I don't expect that I or the original afio author can come up with new information that would make the license situation more clear to the Debian community. So it is basically up to the Debian community to make a choice how they want to apply their labels 'free' and 'nonfree' with respect to afio. The issue has been open for some 2 years now, so maybe it is not unreasonable to indefinitely postpone the legal/social contract discussion about what these labels mean for afio, and make a choice based on purely pragmatic considerations instead. If there are benefits to end users in moving it to non-free, over the current situation, that sounds good to me. BTW I am hoping to make a new up-stream maintenance release before the end of 2012. No promises however. Cheers, Koen. On Wed, 28 Dec 2011, Michael Prokop wrote: * Dean Townsley [Son Apr 24, 2011 at 05:52:00 -0500]: This seems a very sad situation. Is it possible to move afio to non-free and then open a never-ending bug that says it should be moved to main? At least then it will be easier to install. It appears that a license change is nigh unworkable, if not actually impossible. But it does not appear that anything else will satisfy the detractors at this point. This is so sad because by both text and testament the license was intended to allow distribution in both commercial and non-commercial collections. But this certainly isn't the only case where an author didn't try hard enough to give their work away. Ping, any news from the maintainer or anyone else interested in resolving this licensing issue to get afio into wheezy? regards, -mika- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#565202: afio: verification against filesystem does not work
Hi Erik, Sorry for the late reply, looks like I did not notice these bug mail messages the first time among the spam.. Yes, I confirm that this is either a bug or an undocumented shortcoming, depending on how you look at it. As to the why: the -r code was not written to perform a 100% solid comparison, its main purpose is to discover bit errors on the backup medium. The manpage already has something about this: The -r option verifies the file contents of the files in the archive against the files on the filesystem, but does not cross-check details like permission bits on files, nor does it cross-check that archived directories or other non-file entities still exist on the filesystem. but this warning should be extended I guess. A fix would be to stat() the file on the filesystem when the file in the archive has 0 length. Cheers, Koen. On Wed, 13 Jan 2010, Erik Schanze wrote: Hi Koen, [please keep at least 565202-forwar...@bugs.debian.org in CC:] a Debian user has filed a bugreport against Afio, please see below. It seems the problem is, that empty files within Afio archive will not be checked against file system. See afio.c:2938 --88 case S_IFREG: /* does not check file permissions and access times */ if (asb-sb_size == 0) return (0); --88 Is this intended behavior? If yes, why? And we should document it clearly, I think. Thank you in advance. Bye, Erik Christian Schneider Christian Schneider chschnei...@nurfuerspam.de: Package: afio Version: 2.5-5 Severity: important Hi folks, seems to me, as if the verification of afio archives against the filesystem does not work: $ mkdir foo $ touch foo/A $ find foo/ | afio -o bar.afio $ afio -r bar.afio $ echo $? 0 $ echo baz foo/A $ afio -r bar.afio $ echo $? 0 Returns 0 twice!? This is quite severe IMHO. Can you verify this? Thanks in advance. Regards, Christian -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages afio depends on: ii libc6 2.7-18 GNU C Library: Shared libraries afio recommends no packages. afio suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#291364: afio: During install operation, files are listed as uncompressed even if they weren't
Hi Daniel, On Thu, 20 Jan 2005, Daniel Webb wrote: Package: afio Version: 2.5-2 Severity: minor When using afio -i with the -Z option, files that have errors and don't uncompress are still listed as being uncompressed in the -v output. For example, I intentionally corrupted backup/D1.gz in the afio file, and tried to install it. This is the relevant part of the output: snip afio: backup/D1.gz: Broken pipe afio: inentry xwait(): Exit 2 backup/D1.gz -- uncompressed snip I guess you could say it was uncompressed, but the output was 0 bytes, because the compression program failed. It would be much more useful if the output was backup/D1.gz -- FAILED A small gripe... afio is the best robust backup solution out there. This looks like a good thing to fix. I'll put it in the next afio release. The usual warning applies: I don't know when that release will happen, but it will happen eventually. Note: I'm speaking as the upstream maintainer here, I don't directly control the debian package. Thanks, Daniel Cheers, Koen. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
