[mythtv-users] incomplete Deletes on a shared SMB directory
Michael T. Dean
mtdean at thirdcontact.com
Tue Dec 5 03:39:40 UTC 2006
On 12/04/2006 07:06 PM, Yeechang Lee wrote:
> Michael T. Dean <mtdean at thirdcontact.com> says:
>> There's absolutely nothing more Myth can do about the stub, though,
>> other than an outright delete (instead of delete/truncate)*.
> Can't Jeremy's dilemma be fixed by doing a separate, outright delete
> on the original filename once the truncation routine completes? Ugly,
> yes, but it would work, and could be positioned as an option labeled
> as a "workaround for certain buggy software" or something. It wouldn't
> be the first such in the Myth code, either.
No, because by then we've already deleted the file while we had an open
filehandle. That's what's introducing the ambiguity into the equation.
Basically, by doing this, we're saying to Samba that the file /can/ be
deleted when we're done using it (i.e. when we close it). It's up to
the server to decide when to do the final delete. Samba has accounting
code it uses to determine when the file can be deleted based on when the
SMB/CIFS *client* (i.e. the SMB/CIFS driver you used to mount the
filesystem) closes the file, but--according to reports here--a part of
that equation (either the client or the server) is not 100% reliable.
The /only/ way to "fix" it in Myth is to never delete a file with an
open filehandle. If we do the truncate-based-deletion approach, but
wait until the file is small (and closed) before deleting, then shutting
down mythbackend during a truncation will result in the file never being
deleted and never being truncated past the point when mythbackend was
shut down (i.e. potentially leaving multiple gigabytes of data on disk,
but unreferenced in Myth, and, therefore, unusable).
Therefore, for the truncation code to work reliably regardless of
external influences, we /must/ delete the file after opening it, but
before truncating it.
More information about the mythtv-users