mirror of
https://github.com/kdave/btrfs-progs
synced 2024-12-28 09:02:19 +00:00
018306809b
When we process a clone request, we look up the source subvolume by
UUID, even if the source is the subvolume that we're currently
receiving. Usually, this is fine. However, if for some reason we
previously received the same subvolume, then this will use paths
relative to the previously received subvolume instead of the current
one. This is incorrect, since the send stream may use temporary names
for the clone source. This can be reproduced as follows:
btrfs subvolume create subvol
dd if=/dev/urandom of=subvol/foo bs=1M count=1
cp --reflink subvol/foo subvol/bar
mkdir subvol/dir
mv subvol/foo subvol/dir/
btrfs property set subvol ro true
btrfs send -f send.data subvol
mkdir first second
btrfs receive -f send.data first
btrfs receive -f send.data second
The second receive results in this error:
ERROR: cannot open first/subvol/o259-7-0/foo: No such file or directory
Fix it by always cloning from the current subvolume if its UUID matches.
This has the nice side effect of avoiding unnecessary UUID tree lookups
in that case.
Fixes:
|
||
---|---|---|
.. | ||
balance.c | ||
commands.h | ||
device.c | ||
filesystem-du.c | ||
filesystem-usage.c | ||
filesystem-usage.h | ||
filesystem.c | ||
inspect-dump-super.c | ||
inspect-dump-tree.c | ||
inspect-tree-stats.c | ||
inspect.c | ||
property.c | ||
qgroup.c | ||
quota.c | ||
receive.c | ||
replace.c | ||
rescue-chunk-recover.c | ||
rescue-super-recover.c | ||
rescue.c | ||
rescue.h | ||
restore.c | ||
scrub.c | ||
send.c | ||
subvolume.c |