[mythtv] [mythtv-commits] Ticket #2492: mythtranscode leaving cifsxxxx files behind after transcode finishes

Michael T. Dean mtdean at thirdcontact.com
Sat Dec 30 20:32:25 UTC 2006


On 12/26/2006 01:09 PM, Yeechang Lee wrote:
> Nigel Pearson <nigel at ind.tansu.com.au> says:
>   
>> Some NFS implementations do the same thing
>> (renaming it to .nfsXXXX, where XXXX is a number)
>>     
> I've seen both cifsxxxx

See the entire section "'Dodgy' delete on close" at 
http://us1.samba.org/samba/ftp/slides/cifs2005undocumentedcifs.pdf . 
Highlights:

- The file handle must have been opened with an access mask containing 
DELETE. [i.e. FILE_SHARE_DELETE]
- The state can be set and unset via the SMBtrans2 call SetFileInfo – 
info level SET_DISPOSITION_INFORMATION.
- “Delete on close” seems to be a state attached to a file - but also 
settable at NTCreateX time.
- If set when the last handle to the file is closed it causes the server 
to delete the file.

TTBOMK, setting the appropriate flags cannot be done using standard 
(non-CIFS/SMB, i.e. application-level) open calls. Therefore, setting 
the "delete on close" state is the responsibility of the CIFS 
client--i.e. the kernel's CIFS support (not MythTV).

DELETE_ON_CLOSE seems to be part of the CIFS extended attributes (see 
section "3.11 Extended File Attribute Encoding" at 
http://ubiqx.org/cifs/rfc-draft/draft-leach-cifs-v1-spec-02.html ), and, 
therefore, likely requires /both/ client (kernel config option 
CIFS_XATTR, and possibly CIFS_POSIX) and server support (Samba 3.10+) 
for CIFS extended attributes. Since the kernel's help documentation 
says, "If unsure, say N" for both CIFS_XATTR and CIFS_POSIX, I wouldn't 
be surprised if most distros do not enable these options (they are not 
modules, but options for the CIFS module).

Can someone who's experiencing problems verify whether or not their CIFS 
modules are compiled with CIFS_XATTR and CIFS_POSIX support and provide 
information on their server implementation?

>  and .nfsxxxx on my NAS that can handle both
> SMB and NFS mounts. The difference is that, when the truncation is
> complete, the .nfsxxxx file goes away on its own.
>   

At http://nfs.sourceforge.net/
-----
D2. What is a "silly rename"? Why do these .nfsXXXXX files keep showing up?

A. Unix applications often open a scratch file and then unlink it. They 
do this so that the file is not visible in the file system name space to 
any other applications, and so that the system will automatically clean 
up (delete) the file when the application exits. This is known as 
"delete on last close", and is a tradition among Unix applications.

Because of the design of the NFS protocol, there is no way for a file to 
be deleted from the name space but still remain in use by an 
application. Thus NFS clients have to emulate this using what already 
exists in the protocol. If an open file is unlinked, an NFS client 
renames it to a special name that looks like ".nfsXXXXX". This "hides" 
the file while it remains in use. This is known as a "silly rename." 
Note that NFS servers have nothing to do with this behavior.

After all applications on a client have closed the silly-renamed file, 
the client automatically finishes the unlink by deleting the file on the 
server. Generally this is effective, but if the client crashes before 
the file is removed, it will leave the .nfsXXXXX file. If you are sure 
that the applications using these files are no longer running, it is 
safe to delete these files manually.

The NFS version 4 protocol is stateful, and could actually support 
delete-on-last-close. Unfortunately there isn't an easy way to do this 
and remain backwards-compatible with version 2 and 3 accessors.
-----

Important points being:
- "clients have to emulate [delete on last close] using what already 
exists in the protocol"
- "servers have nothing to do with this [silly rename] behavior"
- "After all applications on a client have closed the silly-renamed 
file, the client automatically finishes the unlink by deleting the file 
on the server."
- "if the client crashes before the file is removed, it will leave the 
.nfsXXXXX file"

Note, also, that the NFS client is the NFS-client support in the 
kernel--not MythTV/mythbackend/mythfrontend.

So, to me, it seems that most distros provide a properly-configured NFS 
client with a working silly-rename implementation, but--it seems based 
on the number of people talking about this issue--they provide no 
support (or partial support) for CIFS-based delete-on-close behavior.

If anyone really wants to diagnose the issue with CIFS, I think--rather 
than looking at MythTV's code--he/she should enable CIFS_DEBUG2 (as well 
as CIFS_XATTR and/or CIFS_POSIX), do some testing, and, if necessary, 
discuss the issue(s) at https://lists.samba.org/mailman/ .

Mike


More information about the mythtv-dev mailing list