Renaming a folder succeeds in the following scenario when it should actually fail: 1. Client 1 has opened the file temp.doc which is present in the directory TESTDIR 2. Client 2 tries to rename the directory TESTDIR to DIR1 and it succeeds. On the other hand, if the windows client tries to rename a directory from client 2 wherein client 1 has opened a file under that directory, the operation results in access denied. Samba also sends access denied error when we try to rename the directory from the same client where the file is opened under it. In this case, the following code takes care of returning the appropriate error: /* If no pathnames are open below this directory, allow the rename. */ if (file_find_subpath(fsp)) { return NT_STATUS_ACCESS_DENIED; } file_find_subpath() goes through the connection list for that particular client and if a directory has file open under it, it returns access denied. The reason this code is not working in case of multiple clients is because the connection list is specific to a particular SMBD process and not visible to other SMBD processes. As for as I understand, the only way the other SMBD processes can know if the file in a directory is open is through locking.tdb. But traversing locking.tdb to find an open file under a particular directory can be a tedious operation. Is there a simpler way by which we can find out if the file is open under a directory when we try to rename it?
Is there a specific application that fails due to this? We are living with this limitation since Samba exists. So far nobody has really taken notice. Is this a real issue for you, or is this out of a correctness-test for protocol conformance?
By the way, according to http://msdn.microsoft.com/en-us/library/ff469288.aspx NTFS does the equivalent of a full traverse of locking.tdb. So directory renames on a busy file server must be pretty expensive for them as well.
Probably we have to traverse locking.tdb. In particular in a ctdb environment this will be a royal pain in the neck. We NEED to make this async, probably even fork a separate process for this. There might be hundreds of thousands of open files on a busy file server, and it might take minutes before a traverse goes through.
>>>> Is there a specific application that fails due to this? ... Is this a real issue for you, or is this out of a correctness-test for protocol conformance? This issue was figured out during correctness-test for protocol conformance. We do not have an application that is failing due to the lack of this functionality. Thanks, Shilpa
> know if the file in a directory is open is through locking.tdb. But traversing > locking.tdb to find an open file under a particular directory can be a tedious > operation. Is there a simpler way by which we can find out if the file is open > under a directory when we try to rename it? When /dir/subdir/file is opened you can increment a counter for /dir and /dir/subdir. But is this a smb protocol requirement? Or is it specific to NTFS? Or to Windows VFS ? I think the proper way to do this is through an _optional_ module that enforces more closely ntfs semnatics.
(In reply to comment #5) > When /dir/subdir/file is opened you can increment a counter for /dir and > /dir/subdir. Sure, you could. But that would make open/close very expensive. In a cluster, you might have many nodes which would have to update the /dir counter in a central location every time someone opens or closes a file. This would serialize all opens and closes, and we want to be as independent as possible. Also, this penalizes all opens and closes, which are very frequent relative to directory renames. So I'd rather go and do a global search on dir renames. > But is this a smb protocol requirement? Or is it specific to NTFS? Or to > Windows VFS ? Not sure where this comes from. The documentation suggests that it might be NTFS, but we don't have access to the internal Windows structures. > I think the proper way to do this is through an _optional_ module that enforces > more closely ntfs semnatics. Possibly, yes.