GNOME Bugzilla – Bug 720741
Port from iso-read to libarchive
Last modified: 2016-03-31 13:22:07 UTC
Follow-up from IRC: <hadess> [15:14:49] zeenix, why do you use iso-read instead of libarchive directly for boxes? <zeenix> hadess: does it do UDFs now? if thats there now, we can use it <zeenix> hadess: the API wasn't very intuitive at all last i checked and not very vala-friendly so it wont be a trivial port <hadess> zeenix, no, but the main difference would be filenames, which you can easily work-around <hadess> the API is a bit raw, but it's better than shelling out <hadess> zeenix, did you check that the shell argv parameters are escaped properly? <zeenix> hadess: don't think so, no :( <zeenix> i did test it though <zeenix> hm.. actually this code path is no longer used for UDFs <hadess> right, it'll work if you don't have any funny characters in the iso name :)
This is related to https://code.google.com/p/libarchive/issues/detail?id=362 and Bug #730640 (which introduces a simple libarchive wrapper to Boxes). I think we should use iso-read until the libarchive bug is at least further investigated.
The problem does probably lie in the hardlinks in the archive. (See https://code.google.com/p/libarchive/issues/detail?id=362 again.) This seems to be a rather complex matter: https://github.com/libarchive/libarchive/wiki/Hardlinks Therefore I propose to postpone the hardlink issue for the libarchive wrapper (I want to concentrate on the project goals right now). We could solve this bug through simply change the kernel and initrd paths to the real files instead of the hardlinks. Then it would be really simple to replace the iso-read dependency with libarchive. (In fact I did this already locally, this was when I found the hardlink-bug.)
[Reference] The libarchive wrapper is tracked here: https://bugzilla.gnome.org/show_bug.cgi?id=730640
(In reply to comment #2) > The problem does probably lie in the hardlinks in the archive. (See > https://code.google.com/p/libarchive/issues/detail?id=362 > again.) > > This seems to be a rather complex matter: > https://github.com/libarchive/libarchive/wiki/Hardlinks > > Therefore I propose to postpone the hardlink issue for the libarchive wrapper > (I want to concentrate on the project goals right now). > > We could solve this bug through simply change the kernel and initrd paths to > the real files instead of the hardlinks. Then it would be really simple to > replace the iso-read dependency with libarchive. (In fact I did this already > locally, this was when I found the hardlink-bug.) I don't quite follow. First you say its complicated and then you say the solution is simple. Isn't it the ISO that is using the hardlinks rather than us?
(In reply to comment #3) > [Reference] > The libarchive wrapper is tracked here: > https://bugzilla.gnome.org/show_bug.cgi?id=730640 You want to put it as dependency of this bug then.
(In reply to comment #4) > (In reply to comment #2) > > The problem does probably lie in the hardlinks in the archive. (See > > https://code.google.com/p/libarchive/issues/detail?id=362 > > again.) > > > > This seems to be a rather complex matter: > > https://github.com/libarchive/libarchive/wiki/Hardlinks > > > > Therefore I propose to postpone the hardlink issue for the libarchive wrapper > > (I want to concentrate on the project goals right now). > > > > We could solve this bug through simply change the kernel and initrd paths to > > the real files instead of the hardlinks. Then it would be really simple to > > replace the iso-read dependency with libarchive. (In fact I did this already > > locally, this was when I found the hardlink-bug.) > > I don't quite follow. First you say its complicated and then you say the > solution is simple. Isn't it the ISO that is using the hardlinks rather than > us? Sorry for being so unclear. There are two possible solutions for this bug. 1. [simple] Change the path in libosinfo to the real file instead of the hardlink 2. [complicated] Change the libarchive wrapper to support hardlinks My proposal was to do the 1st so that we can use libarchive for this and do 2nd later because I don't have time for this right now.
(In reply to comment #5) > (In reply to comment #3) > > [Reference] > > The libarchive wrapper is tracked here: > > https://bugzilla.gnome.org/show_bug.cgi?id=730640 > > You want to put it as dependency of this bug then. I dont think I have the access level here to do such a thing.
Im(In reply to comment #7) > (In reply to comment #5) > > (In reply to comment #3) > > > [Reference] > > > The libarchive wrapper is tracked here: > > > https://bugzilla.gnome.org/show_bug.cgi?id=730640 > > > > You want to put it as dependency of this bug then. > > I dont think I have the access level here to do such a thing. nm... Found it. Sorry for the noise.
(In reply to comment #6) > (In reply to comment #4) > > (In reply to comment #2) > > > The problem does probably lie in the hardlinks in the archive. (See > > > https://code.google.com/p/libarchive/issues/detail?id=362 > > > again.) > > > > > > This seems to be a rather complex matter: > > > https://github.com/libarchive/libarchive/wiki/Hardlinks > > > > > > Therefore I propose to postpone the hardlink issue for the libarchive wrapper > > > (I want to concentrate on the project goals right now). > > > > > > We could solve this bug through simply change the kernel and initrd paths to > > > the real files instead of the hardlinks. Then it would be really simple to > > > replace the iso-read dependency with libarchive. (In fact I did this already > > > locally, this was when I found the hardlink-bug.) > > > > I don't quite follow. First you say its complicated and then you say the > > solution is simple. Isn't it the ISO that is using the hardlinks rather than > > us? > > Sorry for being so unclear. > > There are two possible solutions for this bug. > > 1. [simple] Change the path in libosinfo to the real file instead of the > hardlink > > 2. [complicated] Change the libarchive wrapper to support hardlinks > > My proposal was to do the 1st so that we can use libarchive for this and do 2nd > later because I don't have time for this right now. Yeah, that makes perfect sense. Please do provide the required libosinfo patch.
> Yeah, that makes perfect sense. Please do provide the required libosinfo patch. Done. I'll provide the needed patches once the libosinfo patch is applied.
Short update: The libarchive wrapper tracked on Bug#730640 got hardlink support. I already tested the wrapper with the fedora initrd hardlink (works ;)).
Created attachment 277694 [details] [review] iso-extractor: Use libarchive for extraction Note that you have to apply the patches from Bug#730640 first for this to work. In my testcases this worked without problems.
Review of attachment 277694 [details] [review]: ack
Attachment 277694 [details] pushed as b3342f6 - iso-extractor: Use libarchive for extraction