[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