Supporting it may be not so confusing, but it may need
a little format change to record tree and inode number.
I think it's not so acceptable.
Regards,
taruisi
(2009/12/16 2:31), David Nicol wrote:
> how about supporting the operation, as a feature, and allowing a file
> to be in two different su
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 l
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 of
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 a
[cc: Chris -- This, or something like it, should probably go to
stable, but it needs to make it to upstream somewhere first.]
On Sun, Dec 13, 2009 at 6:42 PM, TARUISI Hiroaki
wrote:
> Hi,
>
> We can see the patch in ML archive or at 'Patchwork' site.
>
> http://patchwork.kernel.org/patch/59519/
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 n
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
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.
Hard link contains target inode number but not target tree.
So, if we can create such hard link normally, it points to
a file which has same inode number in
Hi,
I don't know how a hard link becomes to a soft link, hard link
across subvolumes should not allowed in btrfs.
Hard link contains target inode number but not target tree.
So, if we can create such hard link normally, it points to
a file which has same inode number in same subvolume.
As for
Hi all
when I tried to reproduce the bug highlighted by Andrew, I discovered another
bug. When I link a file from a subvolume to another, then remove the subvolume
I got a wrong link: in my test an *hard* link becomes a *soft* link
Steps to reproduce the bug:
r...@venice:/tmp/test
10 matches
Mail list logo
