On 2017/10/02 18:01, Hugo Mills wrote: > On Mon, Oct 02, 2017 at 11:39:05AM +0300, Andrei Borzenkov wrote: >> On Mon, Oct 2, 2017 at 11:19 AM, Misono, Tomohiro >> <misono.tomohiro@xxxxxxxxxxxxxx> wrote: >>> This patch changes "subvol set-default" to also accept the subvolume path >>> for convenience. >>> >>> This is the one of the issue on github: >>> https://github.com/kdave/btrfs-progs/issues/35 >>> >>> If there are two args, they are assumed as subvol id and path to the fs >>> (the same as current behavior), and if there is only one arg, it is assumed >>> as the path to the subvolume. Therefore there is no ambiguity between subvol >>> id and subvol name, which is mentioned in the above issue page. >>> >>> Only the absolute path to the subvolume is allowed, for the safety when >>> multiple filesystems are used. >>> >>> subvol id is resolved by get_subvol_info() which is used by "subvol show". >>> >>> change to v2: >>> restrict the path to only allow absolute path. >> >> This is absolutely arbitrary restriction. Why we can do "btrfs >> subvolume create ./relative/path" but cannot do "btrfs subvolume >> set-default ./relative/path"? > > Indeed. In fact, it's precisely the _opposite_ of the way that > every other command works -- you provide the path to the subvolume in > the *current namespace*. > > This approach would be just a major misfeature at this point. > > Hugo. > Ok, I understood the point and want to revert this. Please review the first version if possible: https://mail-archive.com/linux-btrfs@xxxxxxxxxxxxxxx/msg68486.html Thanks, Tomohiro -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
