(GNU extensions 'K' and 'L').
We correctly handle them when untarring now, but unfortunately
we still don't use them when tarring! That stupid 100 char limit
is still there!
The biggest problem is that we don't support 'pax' tar format.
Linux kernel tarballs are in this format... shame
* unpack: handle tar header fields which are not NUL terminated
* pack: handle 4+GB files correctly
* pack: refuse to store 101+ softlinks (was truncating link
target name)
* pack: mask mode with 07777
things like xasprintf() into xfuncs.c, remove xprint_file_by_name() (it only
had one user), clean up lots of #includes... General cleanup pass. What I've
been doing for the last couple days.
And it conflicts! I've removed httpd.c from this checkin due to somebody else
touching that file. It builds for me. I have to catch a bus. (Now you know
why I'm looking forward to Mercurial.)
dev_t. This is especially important now that the user space concept of a dev_t
and the kernel concept of a dev_t are divergant. The only bit of user space
allowed to know the number of major and minor bits is include/sys/sysmacros.h
(i.e. part of libc). When used with a current C library and a 2.6.x kernel,
this fix should allow BusyBox to support wide device major/minor numbers.
-Erik
This is a bulk spelling fix patch against busybox-1.00-pre10.
If anyone gets a corrupted copy (and cares), let me know and
I will make alternate arrangements.
Erik - please apply.
Authors - please check that I didn't corrupt any meaning.
Package importers - see if any of these changes should be
passed to the upstream authors.
I glossed over lots of sloppy capitalizations, missing apostrophes,
mixed American/British spellings, and German-style compound words.
What is "pretect redefined for test" in cmdedit.c?
Good luck on the 1.00 release!
- Larry
archive_xread can be replaced with bb_full_read, and archive_copy_file
with bb_copyfd*
bb_copyfd is split into two functions bb_copyfd_size and bb_copyfd_eof,
they share a common backend.
Use the old fork() method of tar compression support, rather than
read_bz2....
- (*uncompress)(int in, int out) seems like a more natural interface
for compression code.
- it might improve performance by seperating the work into one cpu
bound and one io bound process.
- There is extra code required to do read_[gz|bunzip] since (*uncompress)(int in,
int out) will normally be used by the standalone compression applet.
There have been problems with this method so if you see a "Short read"
error let me know.
