[mythtv-users] find_orphans.py won't delete files

Michael T. Dean mtdean at thirdcontact.com
Sun Jun 19 19:10:19 UTC 2011


On 06/19/2011 02:41 PM, Jay Ashworth wrote:
> From: "Michael T. Dean"
>> Are your recording files stored on a CIFS/SMB network mount? The error,
>> "eno: Text file busy (26)", sounds a lot like the Windows, "only one
>> user can touch a file at a time," design (flaw?).
> No, that error has a very specific cause, and is -- assuming the error
> number is actually correct -- only supposed to happen in one circumstance:
>
> It has to do with a compilation option you can set on a binary that makes
> the "text segment" be cleanly separated from any related initialized data.
>
> Programs which are compiled this way don't need to be written to the swap/
> page file when you run out of RAM, cause the system can reload the pages
> *from the filesystem*.  Obviously, when a binary program goes on the kernel's
> critical path like that, you don't want people messing with it, so writes to
> that file will get that error.
>
> If you get it in the running of a normal packaged end-user app, you've
> almost certainly horked a config file somewhere.

Definitions, shmefinitions.  Embrace and extend.  And all that...  :)

Pretty sure this status code was co-opted by a bunch of network file 
systems to mean they were unable to get a lock when trying to unlink a file.

See /usr/src/linux-`uname -r`/fs/cifs/inode.c (specifically, it seems 
they're using it for renames pending delete, which are used to delete 
files that are opened--similar to NFS's silly-rename trick).  That means 
the user can probably prevent the problem by simply re-disabling the 
(defaults to off) "Delete files slowly" setting so that his backend 
host's CIFS (client) file system driver doesn't try to do something his 
CIFS server can't handle.  That said, I think a better idea is to not 
use CIFS/SMB, but...

Mike


More information about the mythtv-users mailing list