- From: Yaron Goland <yarong@Exchange.Microsoft.com>
- Date: Thu, 27 Jan 2000 12:23:10 -0800
- To: w3c-dist-auth@w3.org
- Cc: Daniel Lovinger <danlo@Exchange.Microsoft.com>, Brian Andrew <brianan@Exchange.Microsoft.com>
- Message-ID: <7DE119D3D0E15543874F7561EECBDBED0282B9A6@BEG.platinum.corp.microsoft.com>
The following is a summary of my conversations with Daniel Lovinger, technical lead for FAT in Windows NT and Brian Andrew, technical lead for NTFS. Any technical mistakes below are due to my own failure to properly understand what Dan and Brian told me. I explained to Brian and Dan that I needed to implement WebDAV over existing NTFS and FAT file systems and that it was critical that our WebDAV implementation allow for multiple simultaneous protocol access through NFS/Win32/SMB/FTP/WebDAV/etc. I asked them, given this requirement, if it would be possible to simulate an atomic delete by just moving the tree we wanted to delete and then begin the file-by-file delete. Both Brian and Dan agreed that the move operation is atomic and that this would allow one to make the entire sub-tree disappear from a particular point in the namespace in a single atomic act. However both Brian and Dan pointed out that the problems really begin once you have moved the tree. The both pointed out that if I insist on allowing multiple access to the files in question through WebDAV as well as FTP/SMB/NFS/Win32/etc. then it would be impossible to perform an atomic delete. The crux of the problem is that NFS, amongst others, does not necessarily refer to files using their path location. They often refer to files using File IDs which are completely independent of location. This means that the attempt to move the files from one part of the namespace to another in order to hide them won't work with NFS. NFS and similar systems will continue to be able to operate on the files, regardless of where they are moved to. This means that even if the move on the sub-directory succeeds it is possible for a NFS client to come in and open (without the filesharedelete flag) or change the ACL on a file and hence prevent us from deleting the file. Even if we attempt to change the ACL on a file to prevent others from accessing the file another user with a File ID and a higher access can always override us. Note the assumption that we are running the WebDAV thread using the authentication of the requesting user. This is standard practice in NT as we have found that running threads at the administrative level is a security and performance threat. However, even if we were willing to run the WebDAV thread at administrative level in a shared file system it is possible for other administrators to override the local administrator thus causing the previous problems. The result is that the atomic move provided by the file system doesn't buy us much because it doesn't "hide" the files from everyone. This means that there is no way for us to be sure, once we begin actually deleting files, that we will successfully be able to delete all of this files. This then means that we can end up with a half deleted tree. A tree we can not subsequently move back after the failures because to do so would violate the atomic guarantee of an all-or-nothing delete. So the bottom line is that we can't implement an atomic delete and allow for multiple simultaneous file system access through multiple protocols. Since our users absolutely demand multiple simultaneous file system access through multiple protocols we can not implement atomic delete. Yaron
Received on Thursday, 27 January 2000 15:41:09 UTC