BZ_NO_COMPRESS support to the bzip2 sources directly (yes, this takes file
off the vendor branch, but looks like bzip2 maintainer doesn't care), so that
it will not be removed when the next upgrade is performed. Also, add a short
note on how to test bzip2 support.
Pointy hat to: obrien
Correct comment (libz -> libbz2) and remove useless full path to zutil.h
while I am here.
bzip2 support provided, and amd64 depended on. Amd64 has a custom
${.OBJDIR}/machine symlink in it and the -I. picked this up. Without
it, the libstand code was being compiled in 32 bit mode, but with 64 bit
machine headers.
since otherwise the initial seek offset will contain the directory
offset of the filesystem block that contained its directory entry.
This bug was mostly harmless because typically the directory is
less than one filesystem block in size so the offset would be zero.
It did however generally break loading a kernel from the (large)
kernel compile directory.
Also reset the seek pointer when a new inode is opened in read_inode(),
though this is not actually necessary now because all callers set
it afterwards.
- bzipfs and gzipfs now properly return errno values directly from their
read routines rather than returning -1.
- missing errno values on error returns for the seek routines on almost
all filesystems were added.
- fstat() now returns -1 if an error occurs rather than ignoring it.
- nfs's readdir() routine now reports valid errno values if an error or
EOF occurs rather than EPERM (It was just returning 0 for success and
1 for failure).
- nullfs used the wrong semantics for every function besides close() and
seek(). Getting it right for close() appears to be an accident at that.
- read() for buffered files no longer returns 0 (EOF) if an error occurs,
but returns -1 instead.
associated floppy if needed into a static split_openfile() function.
- Use this function in splitfs_open() to open the first chunk rather
than using open() directly. This allows the first chunk to be located
on a different disk than the actual foo.split file.
file in the NFS file system when the underlying device is not a
network device. A Sparc64 specific hack for this exact problem was
already present (nfs.c:1.9, tftp.c:1.10), but the problem is not
specific to Sparc64. The hack has been promoted to a non-i386 test
because on non-i386 architectures it's either impossible to have
non-network devices coexist in the same loader with the NFS FS, or
network and non-network device coexist and NFS filesystems can only
be used on top of network devices. I believe i386 pxeboot is where
this does not hold.
The root cause of this problem is in open.c where each file system
is tried until no more file systems exist or a file system returns
success. There's no notion of a list of valid file systems given
the underlying device and the non-existence of a file can cause
the invalid combination to be tried.
