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