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

[Michael T. Dean]

On 12/02/2006 03:53 PM, Yeechang Lee wrote:
> Chris Pinkham <cpinkham at bc2va.org> says:
>   
>> This is a total hack and shouldn't be required, but you could try adding
>> a call to unlink after the close() in MainServer::TruncateAndClose().
>>     
>
> Sadly, no luck for me; the cifsxxxx stubs still remain. I hope the
> change helps Jerome out, though, since he needs a fix more than I do.

Yeah, the unlink won't work.  The "bug" is in the SMB/CIFS server.  
Until it "knows" for sure that no clients are using the file, the server 
won't delete the leftover.

If Jerome is using an MS implementation of SMB/CIFS, I'd bet that the 
stubs will get cleaned up when a) the SMB/CIFS share is unmounted by 
/all/ clients (not just the Myth box), b) the SMB/CIFS server is 
rebooted, c) when the space is "required" (i.e. like Myth does for 
autoexpire), or d) whenever MS feels like it.  ;)  There's absolutely 
nothing more Myth can do about the stub, though, other than an outright 
delete (instead of delete/truncate)*.  To turn off the delete/truncate, 
disable "slow deletes".  Note, also, that by default, slow deletes are 
disabled.

The most interesting thing is that AIUI Jerome said that the stub has 
the original filename--which means that his server vendor's 
implementation doesn't even bother to alert other clients that a file 
has been deleted (using a silly rename).  /me wonders who made his 
server (an /old/ Samba version, perhaps?)

Mike

*OK, Myth could truncate the file to 1byte, but since the filesystem is 
created with a much larger blocksize--at least 512B (?) and possibly 
much larger (into the MB range)--the file would still take up 1 (much 
larger than 1 byte) block.  The difference, however, is that the user 
would see it as a 1B file and, in many cases, would not know that it 
takes up more space.  Not only because it would lend a false sense of 
security to users, but because the bug's not Myth's, IMHO, this 
shouldn't be done.