[Pan-users] Re: NZB files directly from firefox or other browser or file manager.

[Duncan]

Per Hedeland posted on Tue, 13 Oct 2009 23:21:55 +0200 as excerpted:

>>  (For Linux, at least, you can open the
>>file, creating it, delete it and then close it at exit because the
>>delete will be delayed until after it's closed.  That way, if Pan
>>crashes, the lock still gets removed.
> 
> This is standard Unix filesystem semantics. Exploiting this
> functionality is counter-productive if the file is supposed to be a lock
> file, though. (As far as access via the filesystem is concerned, the
> file ceases to exist at the point of the unlink(2).)

Exactly.  It'll still exist for the application that has it held open, 
because the kernel will ensure that it doesn't get removed from under 
that app, but for the rest of the system, it's gone.  (Well, the entry 
for it is.  I don't believe the space is shown as actually recovered 
until the last app holding it open is terminated.)

If you're seeing other behavior -- if the file continues to exist for 
other apps and thus can act as a lock file after it's deleted with one 
app still holding it open -- that's either a bug, or you're not running 
on a fully compliant Linux (actually, POSIX I believe) filesystem.  VFAT 
or NTFS or something might fail that test, but then they're not full 
POSIX filesystems anyway, but rather platform compatibility filesystems.

FWIW, there's an email that someone still has up on their web page, from 
several years ago, about the lengths to which they had to go at one 
point, to recover a system.  Apparently, the libc and a bunch of other 
stuff had been deleted, and some super-valuable file along with it.  
There was one of those long-running don't-stop-at-any-cost processes 
running, somewhere past half thru a months-long calculation, with the 
file held open, but nothing new could be run because the libc had been 
deleted, and if that app were to finish and close, they'd lose the data 
file, as it had been deleted as well.  The mail describes the hoops this 
guy jumped thru to recover a working system, all without ever stopping 
that single long-running don't-stop-at-any-cost application.  Since that 
app still had the file open, it was still on disk even if the allocation 
for it had been cleared.  One of the steps he did in the recovery was 
directly edit the inodes to put the thing back in place, basically 
undeleting it on a live system.  But he had to do a bunch of other stuff 
too, including restoring a working libc, as it too had been deleted, so 
all he had to work with initially was the existing apps, he couldn't 
start anything, and he had to do it all in the proper order so none of 
the still-there-but-unallocated-data on disk got overwritten.  I don't 
remember the exact details, but it was something very close to the level 
of echoing the appropriate control characters directly to the disk device 
file at the appropriate offset to rewrite the missing allocations, and he 
did something at about that same level at three separate and unrelated 
points in the recovery process.  It certainly impressed me!

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman