Hi Kenny,

That's a really good question - there's not a lot of detail about these files, similar to how the .DS_Store files were years back.

Can you tell me how big the files are that you're finding? I found a customer of ours who reported this to us and the file was over 5GB in size. I suspect that OS X's Finder may be renaming a file to .smbdelete and then doing some form of garbage collection (automated deletes) at some later time. If that's true, then it's a form of asynchronous deletion of a large file so that it doesn't hold up a singe client thread trying to delete something large on a server.

OneFS is usually very fast about deletes of large files (it does its own async delete in the background) so that it can acknowledge to the client that the delete is "done." I wonder if the Mac is doing something similar at a client level so it can quickly acknowledge to a requesting application that a delete is done.

Sadly I have not been able to find anything conclusive in Apple's public open source repository about how this all is supposed to work... that makes me think that Finder (which is closed source) might be responsible for these files, not the OS X SMB client.

Deleting is probably safe to do, but I'd be interested to see if the files you see are particularly large to try to validate my theory.

Thanks,
Bernie

These were multi terabyte files which correlate to the size of the files in this M&E workload, so I think you're right that they were created by the finder. There's gotta be a setting to stop OS X from creating them.

Apple thread (no solution though):

https://discussions.apple.com/thread/3992569?start=0&tstart=0

--

Sent from my iPhone

I've tried a simple repro of first creating a 5.5GB file (via dd on the CLI) from a 10.11.4 Mac against an Isilon SMB share and then deleting the file.

With the CLI, the file deletes normally with rm... no .smbdelete file is created.

With Finder, and only deleting that one file, same thing.

I don't know what triggers the behavior on the Mac yet, or how to disable it. That's a question for Apple methinks.

These .smbdelete files a OS X's way of deleting files that are still kept "open" by some process.

* We have an open file that they want to delete. Use the NFS silly rename
* trick, but try to do better than NFS. The picking of the name came from the
* NFS code. So we first open the file for deletion. Now come up with a new
* name and rename the file. Make the file hidden if we can. Now lets mark
* it for deletion and close the file. If the rename fails then the whole call
* should fail. If the mark for deletion call fails just set a flag on the

* vnode and delete it when we close.

Now that quote is from the actual source code of Apples' SMB client (not Samba!),

taken from OS X 10.10:

http : //www.opensource.apple.com/source/smb/smb-759.40.1/kernel/smbfs/smbfs_smb.c

Watch out for the smbfs_delete_openfile() function.

Bernie, this code has lots of comments about it deals with different server behaviors.

Your engineers should be able to make use of this, and see where OneFS "stands" in terms of interoperability with OS X.

Cheers

Peter

Awesome find Peter! Bernie, is there anything we can do about this?

PS Yan, thanks for finding the Apple thread about it, I pasted the info in there to help those guys out.

I was thinking more along the lines of not allowing it to happen and force the client to get a "file is in use you can't delete it" error.

Wow, nice find Peter! My Google-fu clearly has shortcomings!

Kenny, I think we could assist admins find the .smbdelete files via a find command, and we could do a KB about why these files exist in the first place, but we wouldn't look to delete them ourselves within the code. Automated deletes are a bit of a no-no due to the liabilities involved.

Thanks for this! Saved me some time.

Simple repro with 2 clients.

1. Take a png or other image file and copy it to an Isilon SMB share from one Mac.

2. Open that file from one Mac (client 1) in Preview.

3. Open the same file in Preview on your other Mac (client 2).

4. isi smb openfiles list -v should show 2 IDs that have the same file open for read.

5. From client 1 go into the Finder and delete the file. Finder will not complain and the file will be deleted.

6. On Isilon, you'll see that the file has been renamed to .smbdelete .

7. On client 1 close Preview. The .smbdelete file stays there.

8. On client 2 close Preview. The .smbdelete file remains.

And thus you now have an orphaned .smbdelete file that won't go away.

The .smbdelete file will go away if you close client 2's Preview app before client 1's, but there's no telling how often that will happen in reality.

In 8.0 it might be possible to prevent the .smbdelete file through the use of file filtering, but I haven't tried that out. In the meantime, I think I've got enough of a repro for engineering to see if there's anything they'd like to do.

Kenny Sabarese wrote: I was thinking more along the lines of not allowing it to happen and force the client to get a "file is in use you can't delete it" error.

Gotcha. Let me see what I can do to report this to engineering. If you happen to have any customers that are currently hitting this behavior let me know so we can use their experience to report this to engineering.