Folder can be renamed with an open file inside the same folder from different client

[David Collier-Brown]

The Windows behaviour sounds like a limitation of (at least one of)
their directory implementations.  If the file systems used by samba do
not have that limitation, reproducing the limitation sounds like*
introducing a disfeature.

Two questions seem relevant

 1. Does anyone depend on this bug?  If someone needs a file-tree to be
    unchangeable and/or unreadable during a rename, then reproducing the
    bug/disfeature is desirable in cases where one is trying to provide
    backwards compatibility, or perhaps if one is consciously trying
    provide a strict subset of capabilities. Similarly, does anyone open
    a file because they need to lock a filetree against a rename operation?
 2. Is there any advantage to having it?  Making an operation from one
    client fail because of something another client did is A Bad Thing
    unless and only unless the "other thing" happens to be specifically
    a delete or chmod -w.  Causing a failure in those cases makes sense,
    as the other client is /trying/ to make the tree unwriteable. 
    Causing one in a rename, a chmod -x or the like is changing the
    meaning of rename or chmod.  Not quite a contradiction in terms, but
    genuinely mysterious.

--dave of the
[* I'm back doing ABI work these days, and this discussion sort of
jumped out at me. Under our current and the old David J. Brown rules,
preventing an improved implementation of rename would be considered
seriously bad practice]

--dave



On 10/04/2013 04:32 AM, Volker Lendecke wrote:
> On Wed, Oct 02, 2013 at 12:49:40PM -0700, Jeremy Allison wrote:
>> On Wed, Oct 02, 2013 at 10:09:21AM -0700, Richard Sharpe wrote:
>>> Do we know what Windows does in all cases here?
>>>
>>> For example, if you have a path A\B\C\D which are all folders,
>>> including D, and in D you have files F1, F2, ...
>>>
>>> If you have F1 open, we know that you should not be able to rename D,
>>> but does Windows allow you to rename C or does it disallow renames all
>>> the way up the tree?
>> I think it disallows all the way up the tree, but I'd
>> need to write a torture test to be sure.
> If you look at
> http://msdn.microsoft.com/en-us/library/ff469527.aspx and
> http://msdn.microsoft.com/en-us/library/ff469288.aspx then
> you get the impression that NTFS enumerates all open files
> to check whether there is anything open below a directory to
> be renamed. Probably pretty expensive on a busy fileserver.
>
> Volker
>


-- 
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
davecb at spamcop.net           |                      -- Mark Twain
(416) 223-8968