[mythtv-users] Recordings stay in database and on disk for some time after delete?

[Daniel Kristjansson]

On Fri, 2010-02-26 at 08:58 -0500, Tom Dexter wrote:
> On Thu, Feb 25, 2010 at 9:18 PM, Chris Pinkham <cpinkham at bc2va.org> wrote:
> > * On Thu Feb 25, 2010 at 09:15:53PM -0500, Chris Pinkham wrote:
> >> * On Thu Feb 25, 2010 at 01:04:25PM -0500, Tom Dexter wrote:
> >> > By the way...another thing that appears to have changed since 0.21:
> >> > It used to be the case that, if a number of files where pending slow
> >> > deletes when the backend is stopped, it deleted them as fast as the
> >> > file system allowed before actually stopping.  It doesn't appear that
> >> > occurs any more.  As a matter of fact, when I tried it, not only did
> >> > it not delete the files...it appeared they weren't even getting
> >> > truncated/deleted at all when I restarted the backend (even though
> >> > they were set as deletepending in the recorded table) until I actually
> >> > deleted them again.
> >>
> >> Thanks for mentioning this.  This was a regression introduced in [18792].
> >> I just committed a fix to 0.22-fixes and trunk to restore the original
> >> functionality.
> >
> > I should clarify. The issue fixed is the issue with the files not being
> > deleted if the backend was restarted.  I should have trimmed the quoted
> > text a little more above.

They should be deleted immediately when the backend is stopped. The
way it works is that the delete code opens the file and then tells
the OS to delete the file.. but the OS doesn't do it right away since
the file is open; now MythTV starts slowly truncating the file. if
MythTV is killed before the file has been fully truncated the OS deletes
the file right away because no one has the file open anymore... The
regression was caused by some locking that was preventing the delete
call to the OS from happening until after any in-progress truncates
were finished, that has been fixed in trunk and the fix has been
backported to 0.22-fixes.

-- Daniel