In function handle_global_options(), we reset @optind to 1.
However according to man page of getopt(3) NOTES section, if we need to
rescan options later, @optind should be reset to 0 to initialize the
internal variables correctly.
This explains the reason why in cmd_check(), getopt_long() doesn't
handle the following command correctly:
"btrfs check /dev/data/btrfs --check-data-csum"
While mkfs.btrfs handles mixed non-option and option correctly:
"mkfs.btrfs -f /dev/data/disk1 --data raid1 /dev/data/disk2"
Cc: Paul Jones <paul@pauljones.id.au>
Cc: Hugo Mills <hugo@carfax.org.uk>
Fixes: 010ceab56e ("btrfs-progs: rework option parser to use getopt for global options")
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
As btrfs is specific to Linux, %m can be used instead of strerror(errno)
in format strings. This has some size reduction benefits for embedded
systems.
glibc, musl, and uclibc-ng all support %m as a modifier to printf.
A quick glance at the BIONIC libc source indicates that it has
support for %m as well. BSDs and Windows do not but I do believe
them to be beyond the scope of btrfs-progs.
Compiled sizes on Ubuntu 16.04:
Before:
3916512 btrfs
233688 libbtrfs.so.0.1
4899 bcp
2367672 btrfs-convert
2208488 btrfs-corrupt-block
13302 btrfs-debugfs
2152160 btrfs-debug-tree
2136024 btrfs-find-root
2287592 btrfs-image
2144600 btrfs-map-logical
2130760 btrfs-select-super
2152608 btrfstune
2131760 btrfs-zero-log
2277752 mkfs.btrfs
9166 show-blocks
After:
3908744 btrfs
233256 libbtrfs.so.0.1
4899 bcp
2366560 btrfs-convert
2207432 btrfs-corrupt-block
13302 btrfs-debugfs
2151104 btrfs-debug-tree
2134968 btrfs-find-root
2281864 btrfs-image
2143536 btrfs-map-logical
2129704 btrfs-select-super
2151552 btrfstune
2130696 btrfs-zero-log
2276272 mkfs.btrfs
9166 show-blocks
Total savings: 23928 (24 kilo)bytes
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Returning -ENODATA is only considered invalid on the first run of the
loop where we would detect entirely empty stream.
The enhanced test misc-tests/018-recv-end-of-stream now passes.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=195597
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
The old check here tried to ensure that empty streams are not considered valid.
The old check however, will always fail when only one run through the while(1)
loop is needed and honor_end_cmd is set. So this:
btrfs send /some/subvol | btrfs receive -e /some/
will consistently fail because -e causes honor_cmd_to be set and
btrfs_read_and_process_send_stream() to correctly return 1. So the command will
be successful but btrfs receive will error out because the send - receive
concluded in one run through the while(1) loop.
If we want to exclude empty streams we need a way to tell the difference between
btrfs_read_and_process_send_stream() returning 1 because read_buf() did not
detect any data and read_and_process_cmd() returning 1 because honor_end_cmd was
set. Without introducing too many changes the best way to me seems to have
btrfs_read_and_process_send_stream() return -ENODATA in the first case. The rest
stays the same. We can then check for -ENODATA in do_receive() and report a
proper error in this case. This should also be backwards compatible to previous
versions of btrfs receive. They will fail on empty streams because a negative
value is returned. The only thing that they will lack is a nice error message.
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
testcase:
# ro subvol /src/parent
# rw subvol /src/foo
clone /src/parent/file /src/foo/file
subvol snapshot -r /src/foo /src/foo.snap
# generates a "clone parent/file -> foo.snap/file" send command
send -p /src/parent /src/foo.snap
# target fs:
# dest/
# |--- parent/...
# mounted with -o subvol=dest, such that "parent" is at <target>/parent
receive <target>
result:
ERROR: cannot open dest/parent/file: No such file or directory
expected:
"dest/" get's stripped from the clone source path to get the actual
path in the target fs, if reachable from the mount point/chroot.
This is exactly what process_snapshot does, which gets called on
_every_ incremental receive and I'm quite certain is correct in
doing so
Signed-off-by: Benedikt Morbach <benedikt.morbach@googlemail.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Two fixes:
1)
Check that the parent subvol actually is reachable via our root path.
The previous code wouldn't catch
parent subvol: foo/bar
root path: bar (i.e. mounted with -o subvol=bar)
where the parent isn't reachable from the root path.
(but the original "strstr(parent, root_path) == NULL" check still doesn't hold)
Also check for the slash after "root_path", i.e. throw an error on
parent subvol: foobar
root path: foo
2)
If the parent subvol is the one that is mounted we obviously can't
receive into it, as it has to be read-only by definition.
We'd get a rather cryptic:
At subvol /tmp/test/dest.snap
At snapshot dest.snap
ERROR: creating snapshot / -> dest.snap failed: Invalid cross-device link
(not sure what it says if "/" isn't even a btrfs)
But with this we get
At subvol /tmp/test/dest.snap
At snapshot dest.snap
ERROR: creating snapshot . -> dest.snap failed: Read-only file system
which is both more helpful and more correct.
Signed-off-by: Benedikt Morbach <benedikt.morbach@googlemail.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Regression introduced by a2f7af94ab
"btrfs-progs: subvol_uuid_search: return error encoded pointer"
IS_ERR() will only check if it's an error code, won't check if it's
NULL. And for all the caller the commit modifies, it can return NULL
and makes cause segfault.
Fix it by introducing new IS_ERR_OR_NULL() macro, and for NULL pointer
and needs to return int case, convert NULL pointer to -ENOENT.
Reported-by: Tsutomu Itoh <t-itoh@jp.fujitsu.com>
Tested-by: Tsutomu Itoh <t-itoh@jp.fujitsu.com>
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
This commit changes subvol_uuid_search() to return an error encoded
pointer on failure.
Signed-off-by: Prasanth K S R <prasanth.ksr@dell.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Reword several option descriptions, add missing short option -E,
formatting adjustments.
Visual bug fix: the first line is printed in short help, the second line
is long description, thus alternative calling syntax must be printed on
one line.
Signed-off-by: David Sterba <dsterba@suse.com>
Introduce new option, '--dump' for receive subcommand.
With this command, user can dump the metadata of a send stream.
Which is quite useful for education purpose or bug reporting.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Read buffer helper mistakenly reported end of data as an error. Next, we
have to check if the first stream exists as an empty file is not a valid
stream.
Reported-by: Tsutomu Itoh <t-itoh@jp.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
The utils helper is not verbose in case of an error, for now the helper
used for subvolume listing will print the error message but not
duplicate the ioctl anymore.
Signed-off-by: David Sterba <dsterba@suse.com>
Handle only negative values returned by ioctl syscalls, with exception
of the device remove. It returns positive values that are handled later.
Signed-off-by: David Sterba <dsterba@suse.com>
Noticed this while doing some snapshots in a chroot environment
btrfs receive can set root_path to either realmnt, which is passed in from the
command line, or to a heap allocated via find_mount_root in do_receive. We
should only free the later, not the former, as the former results in an invalid
pointer warning from glibc during free.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: Josef Bacik <jbacik@fb.com>
Signed-off-by: David Sterba <dsterba@suse.com>
- limits.h must be included to pick up PATH_MAX.
- remove double declaration of BTRFS_DISABLE_BACKTRACE
kerncompat.h assumed that if __GLIBC__ was not defined,
it could safely define BTRFS_DISABLE_BACKTRACE, however this can be
defined by the configure script. Added a check to ensure it is not
defined first.
Signed-off-by: Brendan Heading <brendanheading@gmail.com>
Signed-off-by: David Sterba <dsterba@suse.com>
The embedded 'path' is a pointera and we can't make it a path buffer due
to API constraints. Use a separate buffer and sto using the unsafe
path_cat interface.
Signed-off-by: David Sterba <dsterba@suse.cz>
Get rid of the allocation. The logic is changed so that a NULL
cur_subvol::path means that no subvolume/snapshot has been found so far.
Signed-off-by: David Sterba <dsterba@suse.cz>
The path bufferes should be PATH_MAX but BTRFS_PATH_NAME_MAX is shorter
due to embedding in 4k aligned structures.
The only reason to use BTRFS_PATH_NAME_MAX is for the respective
structures btrfs_ioctl_vol_args::name.
Signed-off-by: David Sterba <dsterba@suse.cz>
Kind of a big feature of btrfs is being able to have a default subvol. However
the receive code generates the paths to the subvols from the root of the fs,
even in the case of a default subvol. So instead figure out if we're inside of
a subvol, either because we have a different default or we've chroot'ed and are
using -m. Then strip this extra path off of the subvol we find so we can look
up our parent properly. Thanks
Reported-by: Neil Horman <nhorman@redhat.com>
Signed-off-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
In a chroot environment we may not have /proc mounted, which makes btrfs receive
freak out since it wants to know the base directory where are are mounted for
things like clone and such. Give an option to specify where the mountpoint is
in these cases so you can still do a btrfs receive in a chroot. Thanks,
Signed-off-by: Josef Bacik <jbacik@fb.com>
[added manpage documentation]
Signed-off-by: David Sterba <dsterba@suse.cz>
Capabilities are cleared after chown, and the btrfs-stream encodes the
CHOWN command after any SET_XATTR command. So the capabilites are not
always preserved.
This could be fixed in kernel to emit the instructions in the right
order, but fix in userspace will make it work for older kernels.
If we see the capabilities among xattrs, cache the value and apply it
again in case it's followed by chown on that file.
Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=68891
Reported-by: Juan Orti Alcaine <j.orti.alcaine@gmail.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
This will fix breakage, when doing chrooted receive with cloned paths
outside main subvolume.
Steps to reproduce:
$ create subvolume
$ create file
$ snapshot to snap1
$ delete file
$ snapshot to snap2
$ reflink file from snap1
$ snapsthot to snap3
$ send full snap1 | receive --chroot
$ send incremental snap2 | receive --chroot
$ send incremental snap3 | receive --chroot
The last step would fail with:
Chroot to /mnt/recvdir
At snapshot snap3
ERROR: failed to open /recvdir/snap1/file. No such file or directory
Signed-off-by: Emil Karlson <jekarlson@gmail.com>
[added reproducer]
Signed-off-by: David Sterba <dsterba@suse.cz>
The chroot action seems important enough to be printed unconditionally
and without the verbose option that prints way too much information.
Signed-off-by: David Sterba <dsterba@suse.cz>
This patch forces btrfs receive to issue chroot before
parsing the btrfs stream using command-line flag -C
to confine the process and minimize damage that could
be done via malicious btrfs stream.
Signed-off-by: Lauri Võsandi <lauri.vosandi@gmail.com>
[added long option variant, added docs]
Signed-off-by: David Sterba <dsterba@suse.cz>
glibc 2.10+ (5+ years old) enables all the desired features:
_XOPEN_SOURCE 700, __XOPEN2K8, POSIX_C_SOURCE, DEFAULT_SOURCE; with a
single _GNU_SOURCE define in the makefile alone. For portability to
other libc implementations (e.g. dietlibc) _XOPEN_SOURCE=700 is also
defined.
This also resolves Debian bug report filed by Michael Tautschnig -
"Inconsistent use of _XOPEN_SOURCE results in conflicting
declarations". Whilst I was not able to reproduce the results, the
reported fact is that _XOPEN_SOURCE set to 500 in one set of files
(e.g. cmds-filesystem.c) generates/defines different struct stat from
other files (cmds-replace.c).
This patch thus cleans up all feature defines, and sets them at a
consistent level.
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=747969
Signed-off-by: Dimitri John Ledkov <dimitri.j.ledkov@intel.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Fix the following gcc(>4.9) and clang warning:
In file included from cmds-receive.c:24:
In file included from ./kerncompat.h:22:
In file included from /usr/include/stdio.h:27:
/usr/include/features.h:148:3: warning: "_BSD_SOURCE and _SVID_SOURCE
are deprecated, use _DEFAULT_SOURCE" [-W#warnings]
^
1 warning generated.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Reviewed-by: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Fix the lack of description of "--max-erros" option in
both man and command usage of btrfs receive.
Signed-off-by: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
When calling find_mount_root(), caller in fact wants to find the mount
point of *BTRFS*.
So also check ent->fstype in find_mount_root() and do special error
string output in caller.
This will suppress a lot of "Inapproiate ioctl for device" error
message.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
find_mount_root() function in utils.c should not print error string.
Caller should be responsible to print error string.
This patch will remove the only fprintf in find_mount_root() and modify
the caller a little to use strerror() to prompt users.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Due to either bugs in send (kernel) that generate a command against
a wrong path for example, or transient errors on the receiving side,
we stopped processing the send stream immediately and exited with
an error.
It's often desirable to continue processing the send stream even if an
error happens while processing a single command from the send stream.
This change just adds a --max-errors <N> parameter, whose default value
is 1 (preserving current behaviour), that allows to tolerate N errors
before stopping. A value of 0 means to never stop no matter how many
errors we get into while processing the send stream. Regardless of its
value, errors are always printed to stderr when they happen, just like
before this change.
Signed-off-by: Filipe David Borba Manana <fdmanana@gmail.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
