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 _______________________________________________ Pan-users mailing list Pan-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/pan-users
