Question on streams dir structure creation.
Jeremy Allison
jra at samba.org
Wed Oct 19 18:58:39 UTC 2016
On Wed, Oct 19, 2016 at 06:34:01PM +0000, Hemanth Thummala wrote:
> I have actually found the root cause for server creating the lost-xxxx folders on stream file deletion.
> In streams_depot_unlink(), after deleting the base file we are trying to get the stream directory(16-byte-string) to delete the same. But in stream_dir(), if the stat for streams directory path(.streams/XX/YY/(16-byte-string) exists, we are checking if the file is valid(by validating the SAMBA_STREAMS EA). This will obviously fail as the file itself is deleted. As a result, samba thinks that this is the case of where file is recreated using same inode and tried to restore the streams directory by renaming it to lost-xxxx folder which starts appearing on the share root.
>
> In streams_depot_unlink():
> …
>
> ret = SMB_VFS_NEXT_UNLINK(handle, smb_fname);
>
> if (ret == 0) {
>
> Char *dirname = stream_dir(handle, smb_fname_base,
>
> &smb_fname_base->st, false);
>
> …
>
> }
>
> In stream_dir():
> if (SMB_VFS_NEXT_STAT(handle, smb_fname_hash) == 0) {
> …
> if (!check_valid ||
> file_is_valid(handle, smb_fname->base_name)) { ==> This check fails after base file deletion.
> …
> *Delete lost handling*
>
> Issue is pretty straight forward to reproduce. Create a an alternate data stream file and delete it.
>
> I have made changes to mark the STAT status as invalid and check for valid stat status before doing file_is_valid().
> Another solution I have thought about is handling getxattr error code in file_is_valid(). We should always treat “NO SUCH ATTRIBUTE” as false condition. But being skeptical about the consistency of the error code from different FS.
>
> I am sure that there can be multiple ways to address this issue. Please suggest if there is a better way to fix.
So in modenr Samba when we call into streams_depot_unlink()
we've already done the permissions checks to ensure that
the delete should succeed. Same with streams_depot_rmdir().
So the following might be a better solution. Can you try
this and check it works ?
If so I'll add a test and push upstream.
Cheers,
Jeremy.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-s3-vfs-Remove-files-directories-after-the-streams-ar.patch
Type: text/x-diff
Size: 1952 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20161019/35da010b/0001-s3-vfs-Remove-files-directories-after-the-streams-ar.diff>
More information about the samba-technical
mailing list