On 25 June 2012 11:33, <casper....@oracle.com> 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() and unlink(). > But not allowing link & unlink, you force the filesystem to contain only > trees and not graphs. > > It also allows you to create directories were ".." points to a directory > were the inode cannot be found, simply because it was just removed. > > The support for link() on directories in ufs has always given issues > and would create problems fsck couldn't fix. > > 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 case. Anyway, we've added this to the list of mandatory features and see what we can procure with that. Lionel _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
