Fix all the places where we should be using a blk64_t instead of a
blk_t. These fixes are more severe because 64bit values could be
truncated silently.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Darrick J. Wong [Mon, 7 Oct 2013 13:51:35 +0000 (09:51 -0400)]
libext2fs: ind_punch() must not stop examining blocks prematurely
When we're iterating the main loop in ind_punch(), "offset" tracks how
far we've progressed into the block map, "start" tells us where to
start punching, and "count" tells us how many blocks we are to punch
after "start". Therefore, we would like to break out of the loop once
the "offset" that we're looking at has progressed past the end of the
punch range. Unfortunately, if start !=0, the if-break clause in the
loop causes us to break out of the loop early.
Therefore, change the breakout test to terminate the loop at the
correct time.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Darrick J. Wong [Mon, 7 Oct 2013 13:51:20 +0000 (09:51 -0400)]
libext2fs: allow callers to punch a single block
The range of blocks to punch is treated as an inclusive range on both
ends, i.e. if start=1 and end=2, both blocks 1 and 2 are punched out.
Thus, start == end means that the caller wishes to punch a single
block. Remove the check that prevents us from punching a single
block.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Darrick J. Wong [Mon, 7 Oct 2013 13:35:22 +0000 (09:35 -0400)]
libext2fs: rewind extent pointer when totally deleting an extent
During a punch operation, if we decide to delete an extent out of the
extent tree, the subsequent extents are moved on top of the current
extent (that is to say, they're memmmove'd down one slot). Therefore
it is not correct to advance to the next leaf because that means we
miss half the extents in the range! Rereading the current pointer
should be fine.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Darrick J. Wong [Tue, 1 Oct 2013 01:27:28 +0000 (18:27 -0700)]
libext2fs: set the large_file feature flag when setting i_size > 2GB
If someone tries to write a file that is larger than 2GB, we need to
set the large_file feature flag to affirm that i_size_hi can hold
meaningful contents.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Darrick J. Wong [Tue, 1 Oct 2013 01:26:55 +0000 (18:26 -0700)]
libext2fs: only link an inode into a directory once
The ext2fs_link helper function link_proc does not check the value of
ls->done, which means that if the function finds multiple empty spaces
that will fit the new directory entry, it will create a directory
entry in each of the spaces. Instead of doing that, check the done
value and don't do anything more if we've already added the directory
entry.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Theodore Ts'o [Tue, 1 Oct 2013 03:07:27 +0000 (23:07 -0400)]
tests: add test for resize2fs -M with inode table in middle of block group
Eric Sandeen reported that Fedora's mke2fs when compiled for ppc was
creating a file system which caused problems with resize2fs -M.
Closer examination showed that the problem was file system which
looked like this:
Group 0: (Blocks 1-1024)
Primary superblock at 1, Group descriptors at 2-2
Block bitmap at 66 (+65), Inode bitmap at 67 (+66)
Inode table at 68-99 (+67)
Group 1: (Blocks 1025-1246)
Backup superblock at 1025, Group descriptors at 1026-1026
Block bitmap at 1090 (+65), Inode bitmap at 1091 (+66)
Inode table at 1092-1123 (+67)
It's not obvious to me why Fedora's ppc mke2fs is creating file
systems like this (I can't reproduce this on debian ppc systems), but
resize2fs -M should be able to deal with such file systems, which is
what this test is designed to check.
Theodore Ts'o [Tue, 1 Oct 2013 02:55:21 +0000 (22:55 -0400)]
resize2fs: relocate inode table blocks if necessary when shrinking
If the file system is being shrunk, and a block group's inode table
falls beyond the end of the inode table, we need to try to relocate
the inode table blocks.
Theodore Ts'o [Tue, 1 Oct 2013 02:35:14 +0000 (22:35 -0400)]
resize2fs: fix -M size calculations to avoid cutting off the inode table
If the file system's inode table blocks in the last block group are
located in the middle or the end of the block group, it's possible for
resize2fs -M to use a size which will require relocating the inode
table blocks in the last block group. This can lead to all sorts of
problems, so solve it by simply guaranteeing that we will never do
that.
Reported-by: Eric Sandeen <sandeen@redhat.com> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Eric Whitney [Fri, 27 Sep 2013 00:17:09 +0000 (20:17 -0400)]
tests: add another test for uninit extents past eof
Commit d3f32c2db8 was intended to detect extents found outside their
proper location in the extent tree, including invalid extents at the
end of an extent block. However, it incorrectly reported legal
uninitialized extents created by fallocate() at the end of file with
the FALLOC_FL_KEEP_SIZE flag as false positives. xfstests
generic/263 (among others) caught this problem, while the e2fsprogs
test f_uninit_ext_past_eof did not. The latter test failed to
detect the problem in part because it uses a test file whose i_size
is 0.
Add a test derived from the fsx-based test case in xfstests
generic/263 consisting of a file with non-zero length, more than
four extents total, and two uninitialized extents past EOF to
reliably reproduce commit d3f32c2db8's false positive behavior.
Signed-off-by: Eric Whitney <enwlinux@gmail.com> Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Eric Whitney [Mon, 9 Sep 2013 14:53:03 +0000 (10:53 -0400)]
e2fsck: don't report uninit extents past EOF invalid
Commit d3f32c2db8 introduced a regression that caused e2fsck failures
in xfstests generic 013, 070, 083, 091, and 263. Uninitialized
extents created by fallocate() at the end of file with the
FALLOC_FL_KEEP_SIZE flag were identified as invalid. However,
because the file size is not increased when FALLOC_FL_KEEP_SIZE is
used, uninitialized extents can correctly contain blocks located past
the end of file.
Fix this by filtering out possible invalid extents if they are
uninitialized and extend past the block containing the end of file.
Signed-off-by: Eric Whitney <enwlinux@gmail.com> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Zheng Liu [Mon, 5 Aug 2013 05:02:43 +0000 (13:02 +0800)]
libext2fs: fix a coding style for EXT2_NO_MTAB_FILE
When we define an error in lib/ext2fs/ext2_err.et.in, we will always use
EXT2_ET_* prefix for a new error. But EXT2_NO_MTAB_FILE doesn't obey
this rule. So fix it.
Signed-off-by: Zheng Liu <wenqing.lz@taobao.com> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
and we resize the fs in such a way that all of those blocks must
be moved down, we do them one at a time. Eventually we move 1-block
extent A) to a lower block, and then follow it with the other
blocks in the next logical offsets from extent C) in the next
interior node B).
The userspace extent code tries to merge, so when it finds that
logical 13228 can be merged with logical 13227 into a single extent,
it does. And so on, all through extent C), up to block 13250 (why
not 13251? [1]), and eventually move the node block as well.
So we end up with this when all the blocks are moved post-resize:
All those adjacent blocks got moved into extent D), which is nice -
but the next interior node E) was never updated to reflect its new
starting point - it says the leaf extents beneath it start at 13228,
when in fact they start at 13251.
So as we move blocks one by one out of original extent C) above, we
need to keep updating C)'s parent node B) for a proper starting point.
fix_parents() does this.
Once the tree is corrupted like this, more corruption can
ensue post-resize, because we traverse the tree by interior nodes,
relying on their start block to know where we are in the tree.
If it gets off, we'll end up inserting blocks into the wrong part
of the tree, etc.
I have a testcase using fsx to create a complex extent tree which
is then moved during resize; it hit this corruption quite easily,
and with this fix, it succeeds.
Note the first hunk in the commit is for going the other way,
moving the last block of an extent to the extent after it; this
needs the same sort of fix-up, although I haven't seen it in
practice.
[1] We leave the last block because a single-block extent is its
own case, and there is no merging code in that case. \o/
Signed-off-by: Eric Sandeen <sandeen@redhat.com> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Darrick J. Wong [Mon, 9 Sep 2013 14:40:36 +0000 (10:40 -0400)]
resize2fs: use blk64_t and location getters for free_gdp_blocks()
free_gdp_blocks needs to be taught to use 64-bit fields and the appropriate
getters, otherwise it'll truncate high block numbers (when, say, resizing a
>16T fs) and mark the low numbered group descriptor blocks as free. Yikes.
Reported-by: Eric Sandeen <sandeen@redhat.com> Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Darrick J. Wong [Mon, 9 Sep 2013 14:39:29 +0000 (10:39 -0400)]
libext2fs: ext2fs_dup_handle should not alias MMP buffers
It turns out that resize2fs uses ext2fs_dup_handle to duplicate fs handles. If
MMP is enabled, this causes both handles to share MMP buffers, which is bad
news when it comes time to free both handles. Change the code to (we hope) fix
this. This prevents resize2fs from failing with a double-free error when
handed a MMP filesystem.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Eric Sandeen [Mon, 9 Sep 2013 14:33:20 +0000 (10:33 -0400)]
e2fsck: don't try to stop mmp if there is no superblock set up
Under some failure cases, we can get to fatal_error()
without even having a superblock set up. In that case,
ext2fs_mmp_stop() will segfault when it tries to dereference
fs->super.
Check for the existence of a superblock before we go
down the ext2fs_mmp_stop() path to avoid this problem.
Eric Sandeen [Mon, 29 Jul 2013 02:31:44 +0000 (22:31 -0400)]
debugfs: properly set up extent header in do_write
do_write doesn't fully set up the first extent header on a new
inode, so if we write a 0-length file, and don't write any data
to the new file, we end up creating something that looks corrupt
to kernelspace:
EXT4-fs error (device loop0): ext4_ext_check_inode:464: inode #12: comm ls: bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0)
Do something similar to ext4_ext_tree_init() here, and
fill out the first extent header upon creation to avoid this.
Reported-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Eric Sandeen <sandeen@redhat.com> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> Tested-by: Robert Yang <liezhi.yang@windriver.com>
The function deallocate_inode() in e2fsck/pass2.c was buggy in that it
would clear out the inode's mode and flags fields before trying to
deallocate any blocks which might belong to the inode.
The good news is that deallocate_inode() is mostly used to free inodes
which do not have blocks: device inodes, FIFO's, Unix-domain sockets.
The bad news is that if deallocate_inode() tried to free an invalid
extent-mapped inode, it would try to interpret the root of the extent
node as block numbers, and would therefore mark various file system
metadata blocks (the superblock, block group descriptors, the root
directory, etc.) as free and available for allocation. This was
unfortunate.
(Try running an older e2fsck against the test file system image in the
new test f_invalid_extent_symlink, and then run e2fsck a second time
on the fs image, and weep.)
Fortunately, this kind of file system image corruption appears to be
fairly rare in actual practice, since it would require a very unlucky
set of bits to be flipped, or a buggy file system implementation.
e2fsck: check extent-mapped directories with really large logical blocks
E2fsck was missing a check for directories with logical blocks so
large that i_size > 2GB. Without this check the test image found in
the new test f_toobig_extent_dir will cause e2fsck to die with a
memory allocation failure:
libext2fs, tests: allow /etc/mtab file to be missing
The environment variable EXT2FS_NO_MTAB_OK will suppress the error
code EXT2_NO_MTAB_FILE when the /etc/mtab file can not be found. This
allows the e2fsprogs regression test suite to be run in chroots which
might not have an /etc/mtab file.
By default will still want to complain if the /etc/mtab file is
missing, since we really don't want to discourage distributions and
purveyors of embedded systems from running without an /etc/mtab file.
But if it's missing it only results in a missing sanity check that
might cause file system corruption if the file system is mounted when
programs such as e2fsck, tune2fs, or resize2fs is running, so there is
no potential security problems that might result if this environment
variable is set inappropriately.
Ashish Sangwan [Sat, 11 May 2013 03:42:13 +0000 (09:12 +0530)]
mke2fs: calculate journal blocks just after fs initialize
We can calculate journal blocks as soon as blocksize is set.
It will help to figure out wrong journal blocks count earlier.
This will save some un-necessary initialization.
Without patch output =>
mke2fs /dev/sdc1 -J size=1048576
mke2fs 1.42.7 (21-Jan-2013)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
61312 inodes, 244936 blocks
12246 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=251658240
8 block groups
32768 blocks per group, 32768 fragments per group
7664 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376
Allocating group tables: done
Writing inode tables: done
The requested journal size is 268435456 blocks; it must be
between 1024 and 10240000 blocks. Aborting.
Eric Sandeen [Wed, 19 Jun 2013 01:37:05 +0000 (20:37 -0500)]
resize2fs: move bitmaps if shrinking would orphan them
It is possible to have a flex_bg filesystem with block groups
which have inode & block bitmaps at some point well past the
start of the group.
If an offline shrink puts the new size somewhere between
the start of the block group and the (old) location of
the bitmaps, they can be left beyond the end of the filesystem,
i.e. result in fs corruption.
Check each remaining block group for whether its bitmaps
are beyond the end of the new filesystem, and reallocate
them in a new location if needed.
Signed-off-by: Eric Sandeen <sandeen@redhat.com> Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Theodore Ts'o [Sun, 16 Jun 2013 22:58:40 +0000 (18:58 -0400)]
Use ext2fs_cpu_to_be32() instead of cpu_to_be32() in kernel-jbd.h
Avoid compatibility problems by using the byte swapping functions
defined by e2fsprogs, instead of the ones defined in the system header
files. We use them everywhere else, so we should use them in
kernel-jbd.h too.
Theodore Ts'o [Sun, 16 Jun 2013 18:34:59 +0000 (14:34 -0400)]
Try to use secure_getenv() in preference to __secure_getenv()
If secure_getenv() use it in preference to __secure_getenv().
Starting with (e)glibc version 2.17, secure_getenv() exists, while
__secure_getenv() only works with shared library links (where it is a
weak symbol), but not for static links with /lib/libc.a
Andreas Dilger [Sun, 16 Jun 2013 01:45:37 +0000 (21:45 -0400)]
mke2fs: don't set root dir UID/GID automatically
Don't change the root directory's UID/GID automatically just because
mke2fs was run as a non-root user. This can be confusing for users,
and is not flexible for non-root installation tools that need to
create a filesystem with different ownership from the current user.
Add the "-E root_owner[=uid:gid]" option to mke2fs so that the user
and group can be explicitly specified for the root directory. If
the "=uid:gid" argument is not specified, the current UID and GID
are extracted from the running process, as was done in the past.
Signed-off-by: Andreas Dilger <adilger@dilger.ca> Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Andreas Dilger [Sat, 15 Jun 2013 22:44:09 +0000 (18:44 -0400)]
tests: clean up sed filtering of test output
The sed filters for test outputs that are used to remove build and
test specific information (such as version strings, dates, times,
UUIDs) were unconditionally deleting the first line of output. This
would normally contain the tool version string, but in some cases
contained other information that was being lost. This can lead to
difficulty debugging test failures.
The sed filtering has been changed to only remove the actual version
strings. As well, similar filter strings were duplicated throughout
many scripts, and "sed" and "tr" were often called multiple times in
a pipeline. These have been consolidated into a single filter.sed
file to avoid having to maintain these filters in multiple places.
In a few cases, accidentally deleted messages have been restored to
the expect output for the tests. In other cases, trivial whitespace
has been changed in the expect files.
Signed-off-by: Andreas Dilger <adilger@dilger.ca> Signed-off-by: Theodore Ts'o <tytso@mit.edu>
David Jeffery [Fri, 7 Jun 2013 00:04:33 +0000 (20:04 -0400)]
e2fsck: detect invalid extents at the end of an extent-block
e2fsck does not detect extents which are outside their location in the
extent tree. This can result in a bad extent at the end of an extent-block
not being detected.
e2fsck does not detect this bad extent which both overlaps another, valid
extent, and is invalid by being beyond the end of the extent above it in
the tree.
This patch modifies e2fsck to detect this invalid extent and remove it.
Signed-off-by: David Jeffery <djeffery@redhat.com> Signed-off-by: Theodore Ts'o <tytso@mit.edu> Reviewed-by: Eric Sandeen <sandeen@redhat.com>
E2fsck previously was complaining with zero-length extended attributes
if they appeared in the in-inode xattr space. Test to make sure
e2fsck is now happy with such xattrs.
libext2fs: only use override function when reading an 128 byte inode
The ext2fs_read_inode_full() function should not use fs->read_inode()
if the caller has requested more than the base 128 byte inode
structure and the inode size is greater than 128 bytes. Otherwise the
caller won't get all of the bytes that they were asking for, since
there's no way for the fs->read_inode override function can know what
the size of the buffer passed to ext2fs_read_inode_full().
tune2fs: disallow tune2fs to set inode size larger than block size
Disallow tune2fs command to set the inode size to be larger than the
block size. Without this patch, tune2fs makes the file system to be
unmountable.
Steps to reproduce:
1.Create ext4 without flex_bg (or just create ext3)
# mke2fs -t ext4 -O ^flex_bg DEV
2.Set inode size larger than block size
# tune2fs -I 8192 DEV
3. We failed to mount FS
# mount DEV MP
mount: wrong fs type, bad option, bad superblock on /dev/sda7,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
tests: create crcsum progam to support resizing tests
The only checksum program which we can reliably count upon being
installed on all systems is "sum", which is not a particular robust
checksum. The problem with using md5sum or sha1sum is it hat it may
not be installed on all systems. So create a crcsum program which is
used so we can validate that a data file on a resized file system has
not been corrupted.
Theodore Ts'o [Sun, 31 Mar 2013 17:24:39 +0000 (13:24 -0400)]
resize2fs: fix off-line resize of file systems with flex_bg && !resize_inode
When doing an off-line resize2fs of an initially very small file
system, it's possible to run out of reserved gdt blocks (which are
reserved via the resize inode). Once we run out, we need to move the
allocation bitmaps and inode table out of the way to grow the gdt
blocks. Unfortunately, when moving these metadata blocks, it was
possible that a block that had been just been newly allocated for a
new block group could also get allocated for a metadata block for an
existing block group that was being moved.
To prevent this, after we grow the gdt blocks and allocate the
metadata blocks for the new block groups, make sure all of these
blocks are marked as reserved.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> Reported-by: John Jolly <john.jolly@gmail.com>
Theodore Ts'o [Wed, 13 Mar 2013 18:19:16 +0000 (14:19 -0400)]
debugfs: fix command failures for extent_inode commands that take arguments
The extent_inode commands split_node, replace_node, and insert_node
take arguments which resulted in confusing error messages after
succeeding. Fix this.
Jan Kara [Mon, 25 Feb 2013 05:55:05 +0000 (05:55 +0000)]
e2p: Fix 's' handling in parse_num_blocks2()
parse_num_blocks2() wrongly did:
num << 1;
when log_block_size < 0. That is obviously wrong as such statement has
no effect (and the compiler properly warns about it). Callers expect
returned value to be in bytes when log_block_size < 0 so fix the
statement accordingly.
Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Theodore Ts'o [Sat, 23 Feb 2013 03:23:05 +0000 (22:23 -0500)]
chattr: allow clearing the extent flag
In order to support kernels which support conversion of extent-mapped
files to direct/indirect mapped files, remove the sanity check which
prevented clearing the extent flag in chattr. Kernels which don't
support this will simply give an Operation Not Supported error.
Theodore Ts'o [Mon, 28 Jan 2013 14:02:23 +0000 (09:02 -0500)]
debugfs: add sanity check to make sure we never shift 64 bits right
In the tables which are used to parse the fields for the set_fields
command, there should never be a entry which has a size set to 8
bytes, and two pointers defined. Not only would it result in
undefined behavior in the compiled code, it doesn't make any sense and
is definitely a bug.
Reported-by: Xi Wang <xi.wang@gmail.com> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Phillip Susi [Thu, 24 Jan 2013 16:21:56 +0000 (11:21 -0500)]
libext2fs: fix ext2fs_llseek on i386
ext2fs_llseek() was using lseek instead of lseek64. The
only time it would use lseek64 is if passed an offset that
overflowed 32 bits. This works for SEEK_SET, but not
SEEK_CUR, which can apply a small offset to move the file
pointer past the 32 bit limit.
The code has been changed to instead try lseek64 first, and
fall back to lseek if that fails. It also was doing a
runtime check of the size of off_t. This has been moved to
compile time.
This fixes a problem which would cause e2image when built for
x86-32 to bomb out when used with large file systems.
Theodore Ts'o [Mon, 21 Jan 2013 22:15:25 +0000 (17:15 -0500)]
contrib: add thread locking and readdir64_r support to spd_readdir
This is part of a series of improvements from a 2008 version of
spd_readdir.c that somehow didn't make it into the version which we
checked into e2fsprogs git tree.
Theodore Ts'o [Mon, 21 Jan 2013 21:35:16 +0000 (16:35 -0500)]
contrib: add safe_getenv() support to spd_readdir
This is part of a series of improvements from a 2008 version of
spd_readdir.c that somehow didn't make it into the version which we
checked into e2fsprogs git tree.
Theodore Ts'o [Sun, 20 Jan 2013 04:21:11 +0000 (23:21 -0500)]
libext2fs: teach the ext2fs_*_block_bitmap_range2() about clusters
The ext2fs_{mark,unmark,test}_block_bitmap2() functions understand
about clusters, and will take block numbers and convert them to
clusters before checking the bitmap. The
ext2fs_*_block_bitmap_range2() functions did not do this, which made
them inconsistent. Fortunately, nothing has depended on this
incorrect behavior, and in fact most of the usage of these functions
have only recently been added, and only for optimizations that were
only enabled for non-bigalloc file systems.
So this is a change in previously exported functions, but (a) it
doesn't change the behavior at all for non-bigalloc file systems, and
(b) the change is more likely to fix bugs for bigalloc file systems.
For example, this change fixes a problem with resize2fs and bigalloc
file systems.
Theodore Ts'o [Wed, 16 Jan 2013 18:43:36 +0000 (13:43 -0500)]
resize2fs: check in test-resize script
This should be made into a more formal, automated test case, but for
now, save this as script since it's useful for validating resize2fs's
handling of very large file systems.
Phillip Susi [Tue, 15 Jan 2013 20:31:23 +0000 (15:31 -0500)]
e2image: add -a switch to include all data
Normally the raw and QCOW2 images only contain fs metadata.
Add a new switch ( -a ) to include all data. This makes it
possible to use e2image to clone a whole filesystem.
Darren Hart [Fri, 4 Jan 2013 20:00:59 +0000 (12:00 -0800)]
debugfs: add symlink command
Add support for symbolic links using a new symlink command. Modeled
after the do_mkdir() command.
Testing demonstrates both fastlinks and slowlinks work correctly.
Very long target paths fail as the command parsing appears to truncate
the input to somewhere around 256 bytes.
Signed-off-by: Darren Hart <dvhart@infradead.org> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> Cc: "Darrick J. Wong" <darrick.wong@oracle.com> Cc: Andreas Dilger <adilger@dilger.ca>
Darren Hart [Fri, 4 Jan 2013 20:00:58 +0000 (12:00 -0800)]
libext2fs: add the ext2fs_symlink() function
Creating symlinks is a complex affair when accounting for slowlinks.
Create a new function, ext2fs_symlink(), modeled after ext2fs_mkdir().
Like ext2fs_mkdir(), ext2fs_symlink() takes on the task of allocating a
new inode and block (for slowlinks), setting up sane default values in
the inode, copying the target path to either the inode (for fastlinks)
or to the first block (for slowlinks), and accounting for the inode and
block stats. Disallow link targets longer than blocksize as the Linux
kernel prevents this.
It does not attempt to expand the parent directory, instead returning
EXT2_ET_DIR_NO_SPACE and leaving it to the caller to expand just as
ext2fs_mkdir() does. Ideally, I think both of these functions should
make a single attempt to expand the directory.
[ Fixed a few bugs discovered when creating a test case for ext2fs_symlink() ]
Signed-off-by: Darren Hart <dvhart@infradead.org> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> Cc: "Darrick J. Wong" <darrick.wong@oracle.com> Cc: Andreas Dilger <adilger@dilger.ca>
Theodore Ts'o [Tue, 15 Jan 2013 00:29:54 +0000 (19:29 -0500)]
libext2fs: avoid 32-bit overflow in ext2fs_initialize with a 512M cluster size
If the user attemps to create a 512MB cluster, we need to adjust the
defaults to avoid a 32-bit overflow of s_blocks_per_group. Also check
to make sure that the caller of ext2fs_initialize() has not given a
value of s_clusters_per_group that would result in an overflow of
s_blocks_per_group.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> Reviewed-by: Zheng Liu <wenqing.lz@taobao.com>
Theodore Ts'o [Tue, 15 Jan 2013 00:03:11 +0000 (19:03 -0500)]
mke2fs: teach mke2fs to understand -b 4k and -C 256M
The -b and -C options now use parse_num_blocks2() instead of strtol,
so that users can specify -C 256M instead of the much less convenient
-C 268435456.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> Reviewed-by: Zheng Liu <wenqing.lz@taobao.com>
projects / thirdparty / e2fsprogs.git / log
