how about supporting the operation, as a feature, and allowing a file
to be in two different subvolumes at the same time? Would that make
the link semantics too confusing?
--
Is it the time when there isn't time to discuss but there is time to act yet?
--
To unsubscribe from this list: send the
Hi,
I think message:'Operation not permitted' is more
proper for this problem than 'Invalid cross-device
link' simply because this link is not cross-device
link.
Of course, this operation is prohibited not by security
policy but by inner limitation of btrfs, this usage of
EPERM may be a kind of
TARUISI Hiroaki wrote:
Hi,
I think message:'Operation not permitted' is more
proper for this problem than 'Invalid cross-device
link' simply because this link is not cross-device
link.
Of course, this operation is prohibited not by security
policy but by inner limitation of btrfs, this usage
Hi,
We can see the patch in ML archive or at 'Patchwork' site.
http://patchwork.kernel.org/patch/59519/
Thanks,
taruisi
(2009/12/13 3:39), Andy Lutomirski wrote:
TARUISI Hiroaki wrote:
Hi,
I don't know how a hard link becomes to a soft link, hard link
across subvolumes should not
On Saturday 12 December 2009, TARUISI Hiroaki wrote:
Hi,
I don't know how a hard link becomes to a soft link, hard link
across subvolumes should not allowed in btrfs.
I try an explanation below
Hard link contains target inode number but not target tree.
So, if we can create such hard
