If the filesystem is opened in exclusive mode, then device will be
busy by definition, so don't return -EBUSY. This caused mke2fs -j to
fail on the 1.39-WIP (29-Mar-2006) release. (Addresses Debian Bug:
#360652)
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
The x86 assembly instructures for bit test-and-set, test-and-clear,
etc., interpret the bit number as a 32-bit signed number, which is
problematic in order to support filesystems > 8TB.
Added new inline functions (in C) to implement a
ext2fs_fast_set/clear_bit() that does not return the old value of the
bit, and use it for the fast block/bitmap functions.
Added a regression test suite to test the low-level bit operations
functions to make sure they work correctly.
Note that a bitmap can address 2**32 blocks requires 2**29 bytes, or
512 megabytes. E2fsck requires 3 (and possibly 4 block bitmaps),
which means that the block bitmaps can require 2GB all by themselves,
and this doesn't include the 4 or 5 inode bitmaps (which assuming an
8k inode ratio, will take 256 megabytes each). This means that it's
more likely that a filesystem check of a filesystem greater than 2**31
blocks will fail if the e2fsck is dynamically linked (since the shared
libraries can consume a substantial portion of the 3GB address space
available to x86 userspace applications). Even if e2fsck is
statically linked, for a badly damaged filesystem, which may require
additional block and/or inode bitmaps, I am not sure e2fsck will
succeed in all cases.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
This flag when specified to ext2fs_open or ext2fs_initialize indicates
that the application wants the io_channel to be opened in exclusive mode.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Add a new io_channel open flag, IO_FLAG_EXCLUSIVE,which requests that
the device be opened in exclusive (O_EXCL) mode. Add support to the unix_io
implementation for this flag.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Add a dependency to make sure that the subdirectories are created before
creating all of the object files.
Addresses Sourceforge Bug: #1261553
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
We no longer have the sparc assembly code in the header file any more, so we
shouldn't set _EXT2_HAVE_AS_BITOPS_. This would break compiles on the sparc
architectures when using gcc.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
#include <string.h> is needed since the inline functions use memcpy().
(Addresses Sourceforge Bug #1251062)
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Fix a bug when writing an external journal device on an big
endian machine (such as a S/390), where when the number of
block groups is zero, we never end up writing out the
primary superblock at all.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
If fs->now is non-zero, use that as the time instead of the system
time when setting various filesystem fields (last modified time, last
write time, etc.)
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
In ext2fs_add_journal_inode() check for the case where the filesystem
appears to be unmounted, but the device is still apparently busy.
This can happen when the luser doesn't bother to mount /proc and has a
bogus /etc/mtab, but still wants to mount the filesystem before using
tune2fs(?!?). Add a safety check to save him from his own stupidity,
at least on 2.6 kernels. (Addresses Debian Bug #319002)
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
target is a regular file, instead of doing binary searching. It also
fixes a couple of cases where a file descriptor is leaked in the
ext2fs_getsize() routine on error.
Signed-off-by: Andreas Dilger <adilger@clusterfs.com>
ext2fs_test_bit to take an unsigned int for the bit number. Negative
bit numbers were never allowed (and didn't make any sense), so this should
be a safe change. This is needed to allow safe use of block numbers
greater than or equal to 2**31.
The trouble is that it is modifying pointers in place, but doing so via
"void *" types which alias the pointers passed in (which are typically
pointers to a struct.) The inline ext2fs_resize_mem() code may update
the pointer, but the caller is not required to reload the old value it
may have cached in a register, according to the type aliasing rules.
This is causing the caller to dereference the old pointer when compiled
with -O2, resulting in reproducible SEGV, on at least one ia64
configuration.
The compiler *is* required to reload if it sees an update to a dereferenced
char value, though, as chars are defined to alias anything; and memcpy()
is defined to operate on chars. So using memcpy() to copy the pointer
values is guaranteed to force the caller to reload. This has been
verified to fix the problem in practice.
Fixes Red Hat bug #161183.
honor the PAGER and SS_READLINE_PATH environtment variables, and the
test_io io_manager in the ext2fs library honors the TEST_IO_LOGFILE,
TEST_IO_FLAGS, TEST_IO_BLOCK, and TEST_IO_READ_ABORT environment variables.
environment variables if the libraries are called from setuid or setguid
programs, or if kernel believes that the process is not eligible to create
a core dump. In addition, if the libc has __secure_getenv(), use it so that
the libc can also do any additional limitations regarding when libraries can
trust environment variables (i.e., to integrate with systems like SELinux
and Posix capabilities).
stored in inodes into e2fsck.
There are a number of bug fixes and enhancements over the original lustre fsck
BK repository. The biggest one is that this extended attribute values must
be aligned on 4-byte boundaries.
a new inode we make sure that the extra information in the inode (any extra
fields in a large inode and any ea-in-inode information) is cleared. This
can happen when e2fsck creates a new root inode or a new lost+found directory,
or when the user uses the debugfs write, mknod, or mkdir commands. Otherwise,
the newly create inode could inherit garbage (or old EA information) from
a previously deleted inode.
than the GCC 3.4 compile code and triggers compiler warnings on
sparc64. Thanks to Matthias Andree for his analysis and suggestions.
(Addresses Debian Bug #232326)
Remove support for the --enable-old-bitops configure option which
was only for very old sparc systems.
unspecified, to avoid doing something surprising (such as unconditionally
deleting the first directory entry). Directory entries are now deleted
by coalescing them with the previous directory entry if possible, to
avoid directory fragmentation. This is not an issue with the e2fsprogs suite,
but may be a problem for some of the users of libext2fs, such as e2tools.
has its own copy of the orig_super data structure. (This
is a better way of fixing a double-free problem in
resize2fs which Fedora attempted to fix in
e2fsprogs-1.35-double_free.patch. Addresses Red Hat
Bugzilla #132707.)
byte-swapping options to e2fsck. This was the cause of some hard to
reproduce problems that had been reported in the past, and which the
resize_inode changes tickled in a much more repeatable fashion.