This fixes the Lintian warning:
The copyright file refers to the versionless symlink in
/usr/share/common-licenses for the full text of the GPL, LGPL, or GFDL
license, but the package does not appear to allow distribution under
later versions of the license. This symlink will change with each
release of a new version of the license and may therefore point to a
different version than the package is released under. debian/copyright
should instead refers to the specific version of the license that the
package references.
For example, if the package says something like "you can redistribute it
and/or modify it under the terms of the GNU General Public License as
published by the Free Software Foundation; version 2 dated June, 1991,"
the debian/copyright file should refer to
/usr/share/common-licenses/GPL-2, not /GPL.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Due to a fencepost bug, when skipping a block group whose block bitmap
was uninitialized (and hence could not contain any blocks eligible for
relaocation), the block immediately following the block group wasn't
checked as well. If it was in use and required relocation, it
wouldn't get properly relocated, with the result that an inode using
such a block would end up, post resize, with a pointer to a block now
outside the bounds of the filesystem.
This commit fixes this fencepost error.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
If we need to shrink the inode table, we need to make sure the inodes
contained in the part of the inode table we are vacating don't get
reused as part of the filesystem shrink operation. This wasn't a
problem with ext3 filesystems, since the inode table was located in
the block group that was going away, so that location was not eligible
for reallocation.
However with ext4 filesystems with flex_bg enabled, it's possible for
a portion of the inode table in the last flex_bg group to be
deallocated, but in a part of the filesystem which could be used as
data blocks. So we must mark those blocks as reserved to prevent
their reuse, and adjust the minimum filesystem size calculation to
assure that we don't shrink a filesystem too small for the resize
operation to succeed.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
When allocating a new set of block group metadata as part of growing
the filesystem, the resize2fs code assumes that the bitmap and inode
table blocks are in their own block group; an assumption which is
changed by the flex_bg feature. This commit works around the problem
by temporarily turning off flex_bg while allocating the new block
group metadata, to avoid potentially overwriting previously allocated
data blocks.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Hurd doesn't define PATH_MAX, so calculate the exact size needed for
the tdb filename, and allocate it dynamically.
Addresses-Debian-Bug: #521602
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Fixed a potential bug caused by partial returns from the write system
call (especially possible for network connections).
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
This avoids problems when the calling program has open file
descriptors (especially sockets) open.
Also fix up some warn_unused_result warnings from gcc.
Addresses-Launchpad-bug: #305057
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Running e2fsck against a 14.5TB filesystem with -tt it reported
-200904kB for RAM usage in pass3 instead of the correct 2300773kB.
The RAM usage statistics were being printed with %d instead of %u.
Also fix a few places using %ld for inode numbers instead of %lu.
Signed-off-by: Andreas Dilger <adilger@sun.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
When we resize online, the primary superblock gets copied to all
the backups, and of course since we're mounted the NEEDS_RECOVERY
flag is set. A subsequent fsck will find the backups have the
NEEDS_RECOVERY flag set while the primary does not, and this
forces a full fsck pass.
I think this flag can be safely ignored in the flag comparisons.
Addresses-Red-Hat-Bugzilla: #471925
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
This fixes a regression introduced in commit 79a9ab14 which caused
attempts to open external journals to fail due to overly strict
filesystem consistency checks.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
In Red Hat bug #481620 Jerry reported that the libext2fs info page
is not accesable via "info libext2fs" but is via "info libext2fs.info"
and suggested that the following change should fix it.
Additional info from Jerry:
The problem is that makeinfo 4.12 interprets the dot in "libext2fs.info"
to be the end of the description portion of the info entry, even though
it hasn't seen the closing parenthesis yet. Making the reference be to
just "libext2fs" works.
Addresses-Red-Hat-Bugzilla: #481620
Reported-by: Jerry James <loganjerry@gmail.com>
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
This is a regression from commit
8fdf29117f, which attempts to access
current_fs via a feature check before we check that it's open.
Just moving the feature check below the open check should fix it.
Reported-by: Andrew Hecox <ahecox@redhat.com>
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
The Lifetime writes field will probably not be stable as we add new
features to e2fsprogs, so filter it out to avoid spurious test failures.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Starting in 2.6.29, ext4 can be used to support filesystems without a
journal. So if ext2 is not present, and the kernel version is greater
than 2.6.29, and ext4 is present, return a filesystme type of ext4.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
ext4/ext4dev no longer require a journal.
w/o this blkid doesn't recognize after:
# mkfs.ext4 /dev/blah
# tune2fs -O ^has_journal
# blkid /dev/blah
We still must have one ext3-incompat-feature to flag
as ext4(dev) so we shouldn't ever mis-recognize it.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Nice for testing w/o needing to swizzle around system
libraries...
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
The coverity scanner found this one.
If a line in modules.dep has a ":" but no "/" then:
if ((cp = strchr(buf, ':')) != NULL)
*cp = 0;
else
continue;
if ((cp = strrchr(buf, '/')) != NULL)
cp++;
/* XXX else cp is still null */
i = strlen(cp);
... we will deref a null pointer (cp). This can be
demonstrated by putting a line like:
foo.ko:
into modules.dep. The below change just says that if no "/" is
found, treat the whole string as the module name.
Addresses-Red-Hat-Bugzilla: #486997
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Add a check to make sure the argument to the -m option (which
specifies the reserved ratio) is greater than zero.
Addresses-Debian-Bug: #517015
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
This field tracks the lifetime amount of writes to the filesystem. It
will be updated by the kernel as well as by e2fsprogs programs which
write to the filesystem.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
The other problem codes associated with failing to create the
lost+found directory are non-fatal, and this one should be non-fatal
as well. The two places which call e2fsck_get_lost_and_found()
already deal with a failure to create the directory, so there's no
point making this be a fatal error.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
If ext2fs_inode_alloc_stats2() or ext2fs_block_alloc_stats() is passed
an insanely large inode or block number, it's possible for these
functions to overrun an array boundary and cause the calling program
to crash with a memory error.
Detect this case, and since these functions don't return an error
code, print a warning message, much like we do in ext2fs_warn_bitmap2().
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Add a sanity check to makesure that even if the superblock field
s_first_inode is insane, that we won't return an invalid inode number.
(The function will return the error EXT2_ET_INODE_ALLOC_FAIL in that
case.)
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
An deliberately corrupted filesystem with an insanely large
s_first_ino field could cause e2fsck to crash with a seg fault.
Thanks to Eric Sesterhenn for supplying test cases which demonstrated
this issue.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
The previous patch would return EFBIG for any failure called from
ext2fs_get_device_size2(). (I didn't merge this fix with the
preceeding commit to allow merges to happen more easily.)
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Gcc is too stupid to realize that:
const char *usage="String which has no percent signs";
com_err(progname, 0, usage);
is OK. I refuse to bow to stupidity with:
com_err(progname, 0, "%s", usage);
but I will use the string directly for the sake of people who like to
build with -Werror=format-security.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Mandriva apparently uses "mke3fs" as an alias for mkfs.ext3. I'm not
particularly fond of that practice, but we'll include it as legacy
support.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
If a filesystem is built with the stride extended-option (which is
often used in RAID filesystems to make sure the block and inode
allocation bitmaps don't end up hitting one disk platter harder than
the rest), this can cause tune2fs -I to corrupt the filesystem because
it fails to handle the case where the allocation bitmaps are located
after the inode table, where the inode table needs to grow. Handle
this case correctly.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
With flex_bg usually the inode table for most block groups are packed
right against each other, so expanding the inode table size needs
special handling that's not currently in tune2fs.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Add btrfs detection to libblkid, now that the disk format should be
recognizable in the future.
# misc/blkid /tmp/fsfile
/tmp/fsfile: LABEL="mylabel" UUID="102b07f0-0e79-4b42-8a4e-1dde418bbe6d" TYPE="btrfs"
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Theodore Ts'o