[mythtv-users] incomplete Deletes on a shared SMB directory

[Michael T. Dean]

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.

Mike