The Art of SQL Server FILESTREAM - Red Gate Software

Chapter 11: FileTableany files or folders, even those they created themselves. If a user attempts to delete a fileor folder, it will appear to succeed, but a simple refresh of the folder shows that the itemis still there. No error message is shown to the user. This, again, is a departure from theway NTFS permissions are normally set up: the CREATOR OWNER of an object usually hasfull control over that object, including delete permission.Denying the Delete permission to users is effective only to prevent accidental deletion.As we'll discover below, it's not possible to make files read-only on a user-by-user basis.That means that a user with malicious intent can still destroy the contents of the file,even if the file itself cannot be deleted.It is also possible to prevent users from creating new files and folders in a FileTable bydenying the Insert permission in a similar fashion as for the Delete permission. Whena user attempts to create a new file or folder in the FileTable, they will receive an errormessage that looks like the one below (Figure 11-2). This error message is unfortunatelynot very polished.Figure 11-2:Error message when attempting to create a new file or folder.No read-only accessUnfortunately, it is not possible to provide read-only access to certain users or roleswhile providing read and write access to others. When explicitly denying the Updatepermission on the FileTable to a role or user, users are still able to open files and folders,make changes and save those changes using Windows file I/O APIs. However, because the401