summaryrefslogtreecommitdiff
path: root/cmds-receive.c
Commit message (Collapse)AuthorAge
* btrfs-progs: receive: improved error handling in process_snapshotDavid Sterba2016-09-21
| | | | Signed-off-by: David Sterba <dsterba@suse.com>
* btrfs-progs: typo review of strings and commentsNicholas D Steeves2016-06-01
| | | | | Signed-off-by: Nicholas D Steeves <nsteeves@gmail.com> Signed-off-by: David Sterba <dsterba@suse.com>
* btrfs-progs: receive: don't leak open find handleDavid Sterba2016-01-14
| | | | | Resolves-coverity-id: 1348121 Signed-off-by: David Sterba <dsterba@suse.com>
* btrfs-progs: check for negative return value from ioctlDavid Sterba2016-01-12
| | | | | | | 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>
* btrfs-progs: cmd receive: switch to common error message wrapperDavid Sterba2016-01-12
| | | | | | Message texts were adjusted. Signed-off-by: David Sterba <dsterba@suse.com>
* btrfs: only free root_path if it was allocated from the heapNeil Horman2016-01-12
| | | | | | | | | | | | | 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>
* btrfs-progs: simplify empty stirngs checkDavid Sterba2015-11-06
| | | | | | We can do a strlen(str) == 0 in a simpler way. Signed-off-by: David Sterba <dsterba@suse.com>
* btrfs-progs: use android compat headerDavid Sterba2015-09-01
| | | | | | Applies to sources where pthreads are used. Signed-off-by: David Sterba <dsterba@suse.com>
* btrfs-progs: compilation errors when using musl libcBrendan Heading2015-08-31
| | | | | | | | | | | | | - 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>
* btrfs-progs: receive: use static buffer for cur_subvol pathDavid Sterba2015-06-16
| | | | | | | | 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>
* btrfs-progs: send utils: switch callbacks to patch_cat3_outDavid Sterba2015-06-16
| | | | | | | Also switch full_subvol_path to a static buffer as the interface semantics change. Signed-off-by: David Sterba <dsterba@suse.cz>
* btrfs-progs: receive: use static buffer for write_pathDavid Sterba2015-06-16
| | | | Signed-off-by: David Sterba <dsterba@suse.cz>
* btrfs-progs: receive: use static buffer for root_subvol_pathDavid Sterba2015-06-16
| | | | Signed-off-by: David Sterba <dsterba@suse.cz>
* btrfs-progs: send utils: switch callbacks to new helpersDavid Sterba2015-06-16
| | | | | | | Use a local buffer for full path(s) and avoid dynamic allocations that happend to be unchecked. Signed-off-by: David Sterba <dsterba@suse.cz>
* btrfs-progs: receive: use static buffer for source fileDavid Sterba2015-06-15
| | | | | | We should copy the optarg anyway. Signed-off-by: David Sterba <dsterba@suse.cz>
* btrfs-progs: receive: use static buffer for mount point option argumentDavid Sterba2015-06-15
| | | | Signed-off-by: David Sterba <dsterba@suse.cz>
* btrfs-progs: receive: use static buffer for cur_subvolDavid Sterba2015-06-12
| | | | | | | 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>
* btrfs-progs: use PATH_MAX instead of BTRFS_PATH_NAME_MAXDavid Sterba2015-06-12
| | | | | | | | | | 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>
* btrfs-progs: receive: implement the update_extent callbackDavid Sterba2015-06-12
| | | | | | | The callback for the NO_FILE_DATA send flag is missing and would crash if such stream is received. Signed-off-by: David Sterba <dsterba@suse.cz>
* btrfs-progs: make receive work inside of subvolumesJosef Bacik2015-06-12
| | | | | | | | | | | | | 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>
* btrfs-progs: receive: fix minor resource leakDavid Sterba2015-06-09
| | | | | Resolves-coverity-id: 1302985 Signed-off-by: David Sterba <dsterba@suse.cz>
* btrfs-progs: specify mountpoint for recieveJosef Bacik2015-06-02
| | | | | | | | | | | 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>
* btrfs-progs: receive: restore capabilities after chownDavid Sterba2015-05-27
| | | | | | | | | | | | | | | | 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>
* btrfs-progs: use openat for process_clone in receiveEmil Karlson2015-05-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* btrfs-progs: receive: unconditionally print if doing chrootDavid Sterba2015-04-24
| | | | | | | 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>
* btrfs-progs: optionally enforce chroot for btrfs receiveLauri Võsandi2015-04-24
| | | | | | | | | | | 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>
* btrfs-progs: getopt, use symbolic name for argument requirementsDavid Sterba2015-04-08
| | | | Signed-off-by: David Sterba <dsterba@suse.cz>
* btrfs-progs: drop feature defines from C files, in favour of CFLAGS definesDimitri John Ledkov2015-01-27
| | | | | | | | | | | | | | | | | | | | | | 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>
* btrfs-progs: cleanup, move getop long options close to their useDavid Sterba2015-01-19
| | | | | | Move long_option defintions just before getopt_long everywhere. Signed-off-by: David Sterba <dsterba@suse.cz>
* btrfs-progs: Remove deprecated _BSD_SOURCE macro.Qu Wenruo2014-12-19
| | | | | | | | | | | | | | | | 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>
* btrfs-progs: add missing descriptions of '--max-errors' in btrfs-receive ↵Satoru Takeuchi2014-08-22
| | | | | | | | | | documentation 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>
* btrfs-progs: Check fstype in find_mount_root()Qu Wenruo2014-08-22
| | | | | | | | | | | | | | 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>
* btrfs-progs: Remove fprintf() in find_mount_root().Qu Wenruo2014-08-22
| | | | | | | | | | | 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>
* Btrfs-progs: receive, allow to continue after errors happenFilipe David Borba Manana2014-08-22
| | | | | | | | | | | | | | | | | | | | 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>
* Btrfs-progs: receive: remove return type of close_inode_for_writeRakesh Pandit2014-05-02
| | | | | | | | "close_inode_for_write" always returns 0, so just remove its return value and remove dead checking in caller. Signed-off-by: Rakesh Pandit <rakesh@tuxera.com> Signed-off-by: David Sterba <dsterba@suse.cz>
* btrfs-progs: use usage() to replace the warning msg on no-arg usageGui Hecheng2014-03-21
| | | | | | | | | To be consistent with the other cmds, replace the warning msg with usage() when send/receive are used without any args. Signed-off-by: Gui Hecheng <guihc.fnst@cn.fujitsu.com> Signed-off-by: David Sterba <dsterba@suse.cz> Signed-off-by: Chris Mason <clm@fb.com>
* Btrfs-progs: receive: don't output normal message into stderrWang Shilong2014-03-21
| | | | | | | | | Don't output normal messages into stderr, this make xfstests filter output easier. Signed-off-by: Wang Shilong <wangsl.fnst@cn.fujitsu.com> Signed-off-by: David Sterba <dsterba@suse.cz> Signed-off-by: Chris Mason <clm@fb.com>
* Btrfs-progs: receive: fix the case that we can not find the subvolumeWang Shilong2014-01-31
| | | | | | | | | | | | | | | | | | | | | If we change our default subvolume, btrfs receive will fail to find subvolume. To fix this problem, we have three ideas: 1.make btrfs snapshot ioctl support passing source subvolume's objectid. 2.when we want to using interval subvolume path, we mount it other place that use subvolume 5 as its default subvolume. 3.tell the user to mount the toplevel subvol by himself and run receive We's better use the third approach because first patch will bother kernel change and the second approach is not very good for power users. So give this option to users. Reported-by: Michael Welsh Duggan <mwd@md5i.com> Signed-off-by: Wang Shilong <wangsl.fnst@cn.fujitsu.com> Signed-off-by: Miao Xie <miaox@cn.fujitsu.com> Signed-off-by: David Sterba <dsterba@suse.cz> Signed-off-by: Chris Mason <clm@fb.com>
* btrfs-progs: convert remaining uuid buffer declarations to ↵David Sterba2014-01-31
| | | | | | | BTRFS_UUID_UNPARSED_SIZE Signed-off-by: David Sterba <dsterba@suse.cz> Signed-off-by: Chris Mason <clm@fb.com>
* Btrfs-progs: try harder to make btrfs receive successfullyWang Shilong2014-01-31
| | | | | | | | | | | | | | | | | | | | | | | Steps to reproduce: # mkfs.btrfs -f <dev> # mount <dev> <mnt> # mkdir <mnt>/backup # btrfs sub create <mnt>/subv # btrfs sub snapshot -r <mnt>/subv <mnt>/snap1 # btrfs sub snapshot -r <mnt>/subv <mnt>/snap2 # btrfs send <mnt>/snap2 -p <mnt>/snap1 -f sent_file # btrfs receive -f sent_file <mnt>/backup Above steps will make btrfs receive fails with "ERROR: can not find parent subvolume", this is because we try to find parent subvolume by RECEIVED_SUBVOL_KEY,and it will return ENOENT if parent snapshot has not been sent or it has been deleted. Actually, we can try harder to find whether parent subvolume exists by searching uuid key. Signed-off-by: Wang Shilong <wangsl.fnst@cn.fujitsu.com> Reviewed-by: Stefan Behrens <sbehrens@giantdisaster.de> Signed-off-by: David Sterba <dsterba@suse.cz> Signed-off-by: Chris Mason <clm@fb.com>
* Btrfs-progs: fix magic return value in cmds-receive.cWang Shilong2013-10-16
| | | | | | Signed-off-by: Wang Shilong <wangsl.fnst@cn.fujitsu.com> Signed-off-by: David Sterba <dsterba@suse.cz> Signed-off-by: Chris Mason <chris.mason@fusionio.com>
* btrfs-progs: mark static & remove unused from non-kernel codeEric Sandeen2013-09-03
| | | | | | | | Mark many functions as static, and remove any resulting dead code. Signed-off-by: Eric Sandeen <sandeen@redhat.com> Signed-off-by: David Sterba <dsterba@suse.cz> Signed-off-by: Chris Mason <chris.mason@fusionio.com>
* btrfs-progs: drop weird indirections & dead code from send/receiveEric Sandeen2013-09-03
| | | | | | | | | | | | | cmds-recieve.c & cmds-send.c seem to have weird wrappers and indirections, and "groups" of commands which have only one member, which are never referenced in the code. I think these can be removed. Signed-off-by: Eric Sandeen <sandeen@redhat.com> Reviewed-by: Stefan Behrens <sbehrens@giantdisaster.de> Signed-off-by: David Sterba <dsterba@suse.cz> Signed-off-by: Chris Mason <chris.mason@fusionio.com>
* Btrfs-progs: use UUID tree for send/receiveStefan Behrens2013-08-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit changes the btrfs send/receive commands to use the UUID tree to map UUIDs to subvolumes, and to use the root tree to map subvolume IDs to paths. Now these tools start fast and are independent on the number of subvolules/snapshot that exist. Before this commit, mapping UUIDs to subvolume IDs was an operation with a high effort. The algorithm even had quadratic effort (based on the number of existing subvolumes). E.g. with 15,000 subvolumes it took much more than 5 minutes on a state of the art XEON CPU to start btrfs send or receive before these tools were able to send or receive the first byte). Even linear effort instead of the current quadratic effort would be too much since it would be a waste. And these data structures to allow mapping UUIDs to subvolume IDs had been created every time a btrfs send/receive instance was started. It is much more efficient to maintain a searchable persistent data structure in the filesystem, one that is updated whenever a subvolume/snapshot is created and deleted, and when the received subvolume UUID is set by the btrfs-receive tool. Therefore kernel code was added that is able to maintain data structures in the filesystem that allow to quickly search for a given UUID and to retrieve data that is assigned to this UUID, like which subvolume ID is related to this UUID. Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de> Signed-off-by: David Sterba <dsterba@suse.cz> Signed-off-by: Chris Mason <chris.mason@fusionio.com>
* btrfs-progs: Fix the receive code pathingAlex Lyakas2013-04-23
| | | | | | | | | | | | | The receive code was not distinguishing properly between the mount root and the directory to create the received subvolume in. Also make sure the find_mount_root reports an error if it cannot find a match at all. Reported-by: Robert Buhren <robert@robertbuhren.de> Reported-by: Rory Campbell-Lange <rory@campbell-lange.net> Reported-by: Stefan Priebe - Profihost AG <s.priebe@profihost.ag> Signed-off-by: Alex Lyakas <alex.btrfs@zadarastorage.com> Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
* Btrfs-progs: allow to receive to relative directoriesStefan Behrens2013-04-23
| | | | Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
* Btrfs-progs: Fix that BTRFS_FSID_SIZE is used instead of BTRFS_UUID_SIZEStefan Behrens2013-04-23
| | | | | | Both are 16 but it's wrong anyway to use FSID_SIZE for UUIDs. Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
* Btrfs-progs: btrfs-receive optionally honors the end-cmdStefan Behrens2013-04-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A new option is added to btrfs-receive to change the behavior when an <end cmd> is received in the Btrfs send stream. The traditional behavior (which still is the default) is to continue to read the stream until an EOF condition is encountered. If an <end cmd> is received, afterwards either an EOF or a new <stream header> is expected. The new behavior (if the -e option is set on the command line) is to terminate after an <end cmd> is read without the need for an EOF. This allows the stream (e.g. a single TCP stream) to carry additional data or even multiple Btrfs send streams. Old btrfs-send tools used to encode multiple snapshots like this (with 2 snapshots in this example): <stream header> + <sequence of commands> + <end cmd> + <stream header> + <sequence of commands> + <end cmd> + EOF If the new -e option is set, the expected format is like this: <stream header> + <sequence of commands> + <sequence of commands> + <end cmd> The btrfs-send tool is changed in a seperate commit to always use the new format, i.e. to send an <end cmd> only at the end. Note that the currently existing receivers treat <end cmd> only as an indication that a new <stream header> is following. This means, you can just skip the sequence <end cmd> <stream header> without loosing compatibility. As long as an EOF is following, the currently existing receivers handle the new format (if the two new flags are used) exactly as the old one. The goal of changing the semantic of <end cmd> is to be able to use a single stream (one TCP connection) to multiplex a request/response handshake plus Btrfs send streams, all in the same stream. In this case you cannot evaluate an EOF condition as an end of the Btrfs send stream. You need something else, and the <end cmd> is just perfect for this purpose. Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
* Btrfs-progs: small parent_subvol cleanup for cmds-receive.cStefan Behrens2013-04-23
| | | | | | parent_subvol is local to process_snapshot() and not needed outside. Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
* Btrfs-progs: Set the root-id for received subvols in btrfs receiveStefan Behrens2013-04-23
| | | | | | | | | When an entry was added to the subvol search tree, the root_id was always 0 (not set at all) and therefore only the first one was added, all the others had been ignored. This commit sets the root_id before the entry is added. Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
generated by cgit v1.2.3 (git 2.25.1) at 2024-04-19 09:18:14 +0000