summaryrefslogtreecommitdiffstats
path: root/libbb/unarchive.c
Commit message (Collapse)AuthorAgeFilesLines
* Make the array const to fix warning.graham.gower2009-11-151-2/+2
| | | | git-svn-id: http://opkg.googlecode.com/svn/trunk@304 e8e0d7a0-c8d9-11dd-a880-a1081c7ac358
* I'm still seeing leaks here. So just stop allocating for these variables.graham.gower2009-11-151-8/+5
| | | | git-svn-id: http://opkg.googlecode.com/svn/trunk@303 e8e0d7a0-c8d9-11dd-a880-a1081c7ac358
* More cleanup in error paths to plug leaks found while installing dbus.graham.gower2009-11-101-4/+3
| | | | git-svn-id: http://opkg.googlecode.com/svn/trunk@280 e8e0d7a0-c8d9-11dd-a880-a1081c7ac358
* Fix memory leaks.graham.gower2009-11-011-13/+21
| | | | git-svn-id: http://opkg.googlecode.com/svn/trunk@233 e8e0d7a0-c8d9-11dd-a880-a1081c7ac358
* Fix implicit declaration of strnduppixdamix2009-10-281-1/+1
| | | | | | | | s/strndup/xstrndup/ Thanks to Graham Gower <graham.gower@gmail.com> git-svn-id: http://opkg.googlecode.com/svn/trunk@224 e8e0d7a0-c8d9-11dd-a880-a1081c7ac358
* Improve the poor man's fseek in unarchive.cpixdamix2009-10-271-6/+22
| | | | | | | | | | Modified seek_sub_file since the fgetc in the for loop was very slow when installing huge packages. A test on my machine showed a 4x gain when installing a large package (23Mib) git-svn-id: http://opkg.googlecode.com/svn/trunk@222 e8e0d7a0-c8d9-11dd-a880-a1081c7ac358
* Fix opkg doesn't handle long link/path names in tar files wellticktock352009-09-211-3/+4
| | | | | | | | | | | | | 1. provide opkg with a tar file that has a link name that is 100 characters or 2. provide opkg with a tar file that has a 'path_prefix' of 155 characters. Thanks to pblack88@gmail.com http://code.google.com/p/opkg/issues/detail?id=21 git-svn-id: http://opkg.googlecode.com/svn/trunk@217 e8e0d7a0-c8d9-11dd-a880-a1081c7ac358
* Thanks to claudyus84 and Gillesticktock352009-06-261-2/+2
| | | | | | | | | http://www.crisos.org/flyspray/index.php?do=details&task_id=10 Fix issue: http://code.google.com/p/opkg/issues/detail?id=4#c5 git-svn-id: http://opkg.googlecode.com/svn/trunk@214 e8e0d7a0-c8d9-11dd-a880-a1081c7ac358
* Thanks to Antonioticktock352009-03-261-0/+10
| | | | | | | | | | | Propagate gz_open() errors to caller function. This is not enough, it is still needed to check deb_extract return value everywhere in libopkg/pkg_extract.c Signed-off-by: Antonio Ospite <ospite@studenti.unina.it> git-svn-id: http://opkg.googlecode.com/svn/trunk@205 e8e0d7a0-c8d9-11dd-a880-a1081c7ac358
* Thanks to Krzysztof Kotlenga <pocek@users.sf.net>:ticktock352009-03-031-8/+8
| | | | | | | | | | | | | | Frans Meulenbroeks wrote: > Anyway, appending the 0 byte is no good as tar_entry->name[100] is > already out of bounds. http://tiny.cc/964UD looks good enough. It's interesting that we have to trace bugs already fixed upstream years ago. http://lists.linuxtogo.org/pipermail/openembedded-devel/2009-March/008510.html git-svn-id: http://opkg.googlecode.com/svn/trunk@203 e8e0d7a0-c8d9-11dd-a880-a1081c7ac358
* Thanks toticktock352009-02-121-0/+4
| | | | | | | | | | | | | | | | | | Frans Meulenbroeks http://groups.google.com/group/opkg-devel/browse_thread/thread/23c3557277de0f2e If a file name in a tar archive is exactly 100 bytes long the name field is completely filled and there is no terminating null byte; so extraction of the file will yield a name that is extended with the mode (e.g. 000644). The attached patch cures it although there might be better solutions. The problem is also in busybox tar and reported there too. Frans. git-svn-id: http://opkg.googlecode.com/svn/trunk@201 e8e0d7a0-c8d9-11dd-a880-a1081c7ac358
* revert R190, keep R191ticktock352008-12-271-6/+6
| | | | | | | Waiting for the patch fixing bugs. git-svn-id: http://opkg.googlecode.com/svn/trunk@192 e8e0d7a0-c8d9-11dd-a880-a1081c7ac358
* Thanks for Mike Westerhof <mwester@dls.net>ticktock352008-12-271-6/+6
| | | | | | | | | | | | | | | | | | | | | | ---------- This patchset updates the libbb stuff to use a vfork() version of gz_open, called gzvopen. This is done because a standard fork will duplicate the entire address space. This will invoke the OOM (out of memory) killer on small-memory machines, because most often by the time we unzip any package, we've read the entire package database into memory already. By using vfork() and immediatly execing the external gunzip utility, we avoid the need to clone the entire address space. Yes, this is actually **LESS** efficient than the original way! But there is no way to (currently) dodge the OOM killer on a per-process basis, so the alternatives are to either change the OOM killer behavior system-wide, or to use this workaround. Mike Westerhof, Dec 2008 git-svn-id: http://opkg.googlecode.com/svn/trunk@190 e8e0d7a0-c8d9-11dd-a880-a1081c7ac358
* [opkg] trivial, remove unused variable resticktock352008-12-151-1/+0
| | | | git-svn-id: http://opkg.googlecode.com/svn/trunk@148 e8e0d7a0-c8d9-11dd-a880-a1081c7ac358
* opkg: (leak fixing, day 3) fixed final memory leaks fixed reported fromticktock352008-12-151-0/+2
| | | | | | | | running libopkg_test git-svn-id: http://opkg.googlecode.com/svn/trunk@116 e8e0d7a0-c8d9-11dd-a880-a1081c7ac358
* opkg: fix some initialisation and double free issues in libbbticktock352008-12-151-1/+1
| | | | git-svn-id: http://opkg.googlecode.com/svn/trunk@85 e8e0d7a0-c8d9-11dd-a880-a1081c7ac358
* * Rename top level ipkg directory to opkgticktock352008-12-141-10/+10
| | | | git-svn-id: http://opkg.googlecode.com/svn/trunk@8 e8e0d7a0-c8d9-11dd-a880-a1081c7ac358
* * Add ipkg for future developmentticktock352008-12-141-0/+811
git-svn-id: http://opkg.googlecode.com/svn/trunk@3 e8e0d7a0-c8d9-11dd-a880-a1081c7ac358