Arch Linux

Description: There is logic in place to detect whether the root chroot's $chroottype is btrfs, and if it is, make use of the btrfs subvol delete/snapshot features to create a clean copy. This erroneously assumes that, if the root chroot (e.g. /var/lib/archbuild/extra-x86_64/root) is a btrfs subvolume, then the user chroot (e.g. /var/lib/archbuild/extra-x86_64/user), if it exists, will be a btrfs subvolume too. It may actually be a mount point, as is the case in my situation, where it is a 15G tmpfs. Other users may have a similar set up due to HDD space limitations, worries about excessive reading/writing wearing out a HDD, the voices in their head telling them to do it, etc.

Currently the script dies, complaining that $copydir is not a subvolume, when it should (in my opinion) fall back on the traditional/non-btrfs rsync command, which works fine.

Attached is a tiny patch that adds in an additional check to the initial btrfs check. It also includes a typo fix (directoy => directory) which I forgot to remove from the patch and don't think is worth opening a separate bug report for.

Additional info:
devtools-20130408-1-any.pkg.tar.xz

extra-x86_64-build output:
==> Building in chroot for [extra] (x86_64)...
==> Creating clean working copy [user]...ERROR: '/var/lib/archbuild/extra-x86_64/user' is not a subvolume
==> ERROR: Unable to delete subvolume /var/lib/archbuild/extra-x86_64/user


Steps to reproduce:
Have a filesystem mounted at a user chroot location, then run a helper script (e.g. extra-x86_64-build) in a directory with a PKGBUILD, etc.