with 2.6.x asm/posix_types.h, which has done singularly evil thing
by yanking __kernel_dev_t and renaming it. The loop interface was
really poorly designed in the first place. The new 64 bit loop
interface looks to be somewhat less horrible, too bad it is only
present in 2.6.x kernels.
-Erik
out during the allocation process. When vodz changed it to be allocated on the
stack, he forgot to explicitly zero it, leaving its value filled with whatever
used to be sitting on the stack. It would garbage values, depending on the
garbage that happened to be sitting on the stack when the function was called.
The result was that applets using bb_getopt_ulflags() were showing
unpredictable behavior (such as segfaults), which naturally broke many things.
device ID iff the named file is a character or block special device. Otherwise
it is meaningless junk, in which case st_dev should be used. This was done
incorrectly, which could cause mount to display bogus mount info.
-Erik
cp does not truncate existing destinations. That is, after
running
echo foo > foo
echo fubar > fubar
cp foo fubar
the contents of fubar are
foo
r
instead of
foo
function as there is no gracefull way of handling failures.
Rename bb_getport to bb_lookup_port, allow a default port to be
specified so it always returns a correct value.
Modify ftpgetput/rdate/wget to use the new interface.
wget/rdate now use etc/services with a falback default value.
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.
in order to fix the problems with round robin DNS reported
by Andrew Flegg:
http://busybox.net/lists/busybox/2003-October/009579.html
This removes the ipv6 specific xconnect dns lookups. I do
not see why that would need to be special cased for ipv6 as
was done, but that will just have to be tested.
So IPV6 people -- please test this change!
-Erik
In BusyBox v1.00-pre2,
commands like ls, df with -h option report a wrong file size for files larger than 4GBtye!!
For example,
when I execute 'ls -l', it reports
-rw-r--r-- 1 root root 5368709120 Aug 17 2003 large_stream.tp
when I execute 'ls -lh', I expect that
-rw-r--r-- 1 root root 5.0G Aug 17 2003 large_stream.tp
but it reports
-rw-r--r-- 1 root root 1.0G Aug 17 2003 large_stream.tp
I fixed this bug that...
Line 31 in libbb/human_readable.c and line 275 include/libbb.h
const char *make_human_readable_str(unsigned long size
=> const char *make_human_readable_str(unsigned long long size
It's OK!
