[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