Opened 6 years ago

Last modified 6 years ago

#11221 new Bug Report - General

The use of OpenAndUnlink() in mainserver.cpp::DeleteFile() prevents the use of CIFS

Reported by: dargllun@… Owned by:
Priority: minor Milestone: unknown
Component: MythTV - General Version: 0.26-fixes
Severity: medium Keywords:
Cc: Ticket locked: no


CIFS's implementation of unlink() fails with EBUSY if the file is still open. This is no bug of CIFS, but an intended limitation done in favour of consistent behaviour. So when a file is really to be deleted, the pattern open->unlink should be avoided. A work around for this is to use NFS, but CIFS should be supported as well. Especially when using a NAS, the concurrent use of multiple mount file systems to access the same resource is prone to cause major headaches with file permissions, and also is an additional maintenance burden.

Change History (2)

comment:1 Changed 6 years ago by mtdean@…

Users of CIFS file systems should not enable the setting:

Delete files slowly
Some filesystems use a lot of resources when deleting large files. If enabled, this option makes MythTV delete files slowly on this backend to lessen the impact.

because CIFS does not support the open and unlink behavior used (only) when "Delete files slowly" is enabled.

comment:2 Changed 6 years ago by dargllun@…

The bug happens regardless of the "Delete files slowly" setting. Looking into the source code confirms this has no relevance here.

Please also note that unlink(2) returning EBUSY is perfectly legal, quoting from the man page:


The file pathname cannot be unlinked because it is being used by the system or another process; for example, it is a mount point or the NFS client software created it to represent an active but otherwise nameless inode ("NFS silly renamed").

One certainly can't help if some other process has an open FD on a file one wants to unlink() but open()ing it without need seems a bit like asking for trouble. To be honest I was very surprised to learn all this, because I've known the open-unlink pattern for a long time and was convinced this is standard UNIX. But after all it seems to just be widely available with many file systems, but in no way being a feature you can take for granted. So defensive code should probably not rely on it.

Note: See TracTickets for help on using tickets.