Closed GoogleCodeExporter closed 8 years ago
Take a look in unarchive.c: extract_archive().
Something like the following (untested) patch may do what you want, but its
likely to leave parts of the package on the
system. The current unarchive mess does not pass errors up the call tree,
making it problematic to exit gracefully.
diff --git a/libbb/unarchive.c b/libbb/unarchive.c
index 5e9c13a..4598765 100644
--- a/libbb/unarchive.c
+++ b/libbb/unarchive.c
@@ -150,7 +150,10 @@ char *extract_archive(FILE *src_stream, FILE *out_stream,
const file_header_t *f
stat_res = lstat (full_name, &oldfile);
if (stat_res == 0) { /* The file already exists */
if ((function & extract_unconditional) || (oldfile.st_mtime < file_entry->mtime)) {
- if (!S_ISDIR(oldfile.st_mode)) {
+ if (S_ISLNK(oldfile.st_mode)) {
+ error_msg_and_die("%s: Not overwriting symlink %s with directory",
+ __FUNCTION__, file_entry->name);
+ } else if (!S_ISDIR(oldfile.st_mode)) {
unlink(full_name); /* Directories might not be empty etc */
}
} else {
Original comment by graham.g...@gmail.com
on 23 Nov 2009 at 12:03
Ugh, that sucks. Thanks for taking a look, I'll play with that patch. Any
long term plans
to resolve the archive mess, out of curiosity?
Original comment by kerg...@gmail.com
on 30 Nov 2009 at 4:54
I recently added an error parameter to the unarchive.c functions to pass errors
up the call stack so extraction errors will ensure
early exit with a message now. Unwinding installation of a package may need to
be rethought, because it cannot currently
unwind with errors after a certain point (any extraction errors cause crap to
be left on the system). So adding something like the
above patch probably wouldn't make the situation worse in that regard - at
least your perl package wouldn't get broken.
The --force-overwrite option sets a non global variable conf->force_overwrite.
unarchive.c doesn't have access to this currently.
I'd like to make the conf struct global so that this file (and others) can
access config file and command line parameters. And also
so that we're not passing a conf pointer to almost every function in opkg.
Long term, libbb could use an update from busybox' current stable release. The
unarchiving code in busybox has undergone a
major design change and its new interface would actually make things a lot
nicer to implement what you are asking. But it
doesn't really fit with how opkg works right now. Opkg needs a lot more work
first, otherwise bolting an updated libbb on the
side will inevitably just result in more work later.
So, unarchive/unzip may not be the best, but it works enough to identify and
allow fixes for a bunch of design problems
elsewhere in the code. That will be a priority over importing a new libbb.
Original comment by graham.g...@gmail.com
on 30 Nov 2009 at 8:04
Understood. Thanks again :)
Original comment by kerg...@gmail.com
on 2 Dec 2009 at 3:12
I'm looking at removing unzip/unarchive and replacing with the use of
libarchive which is well maintained and should handle everything a lot better.
Therefore I'm not going to fix anything within those functions now.
Original comment by paul.betafive
on 18 Sep 2013 at 1:25
Original issue reported on code.google.com by
kerg...@gmail.com
on 17 Nov 2009 at 3:44