Re: [PATCH] ncpfs: fix rmdir returns Device or resource busy

[Dave Chiluk]

On 06/12/2013 09:01 PM, Al Viro wrote:
> On Fri, Jun 07, 2013 at 05:14:52PM +0100, Al Viro wrote:
>> On Fri, Jun 07, 2013 at 11:09:05AM -0500, Dave Chiluk wrote:
>>> Can't you just use the patch from my original e-mail?  Anyhow I attached
>>> it an already signed-off patch.
>>>
>>> Al Viro Can you integrate it now?
>>
>> Applied...  FWIW, patch directly in mail body is more convenient to deal with.
I checked
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git
and don't see the change, is there somewhere else you applied it, or has
it just not been uploaded yet.

> 
> Actually, looking at that stuff...  Why are we bothering with -EBUSY for
> removal of busy directories on ncpfs, anyway?  It's not just rmdir(), it's
> overwriting rename() as well.  IS_DEADDIR checks in fs/namei.c and fs/readdir.c
> mean that the only method of ncpfs directories that might get called after
> successful removal is ->setattr() and it would be trivial to add the check
> in ncp_notify_change() that would make it fail for dead directories without
> bothering the server at all...
Sounds sane.

As for rename: mv dir1 dir2 works.  I was expecting it to fail similar
to rmdir, but I'm guessing if I trace the code new_dentry->d_count just
happens to = 1 preventing the error path from being taken.

> 
> Related question: what happens if you open / unlink / fchmod on ncpfs?
> 
fchmod returned errno 13: Permission denied

Let me know if you need anything else tested.  Also, please take
everything I say with a grain of salt as this is the first and hopefully
last time, I will ever have to change code in ncpfs.  Frankly, as it has
clearly fallen into disrepair, I'd actually love to see it deprecated in
favour of any other more active network file systems.

Dave.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/