On Tue, Jun 26, 2012 at 8:12 AM, Lionel Cons
wrote:
> On 26 June 2012 14:51, wrote:
> We've already asked our Netapp representative. She said it's not hard
> to add that.
Did NetApp tell you that they'll add support for using the NFSv4 LINK
operation on source objects that are directories?! I'
>We've already asked our Netapp representative. She said it's not hard
>to add that.
And symlinks don't work for this? I'm amazed because we're talking about
the same file system. Or is it that the code you have does the
hardlinking?
If you want this rfo Oracle, you would need to talk to
On 26 June 2012 14:51, wrote:
>
>>> To be honest, I think we should also remove this from all other
>>> filesystems and I think ZFS was created this way because all modern
>>> filesystems do it that way.
>>
>>This may be wrong way to go if it breaks existing applications which
>>rely on this feat
>> To be honest, I think we should also remove this from all other
>> filesystems and I think ZFS was created this way because all modern
>> filesystems do it that way.
>
>This may be wrong way to go if it breaks existing applications which
>rely on this feature. It does break applications in our
On 25 June 2012 11:33, wrote:
>
>>Does someone know the history which led to the EPERM for unlink() of
>>directories on ZFS? Why was this done this way, and not something like
>>allowing the unlink and execute it on the next scrub or remount?
>
>
> It's not about the unlink(), it's about the link
>Does someone know the history which led to the EPERM for unlink() of
>directories on ZFS? Why was this done this way, and not something like
>allowing the unlink and execute it on the next scrub or remount?
It's not about the unlink(), it's about the link() and unlink().
But not allowing link &
