On Wed, Jan 25, 2012 at 4:40 PM, chas williams - CONTRACTOR <[email protected]> wrote: > On Wed, 25 Jan 2012 13:43:47 -0600 > Andrew Deason <[email protected]> wrote: > >> In general? I think it's a very useful behavior for temporary file >> storage that doesn't linger. If you make a temporary file and just >> unlink when you're done, it'll stick around if the process is killed >> halfway through what it's doing. If you open, and then unlink, it goes >> away if the proc is killed even if you don't cleanup properly. (The >> OpenAFS salvager was semirecently made to use this kind of functionality >> for its temp storage, iirc.) > > this isnt often used. mostly because it hides the file from someone > who doesn't know that the program actually does this. in some cases, i > would almost consider this rogue behavior because you can just fill up > the filesystem and in the case of some programs, ignore write errors > and keep it filled until someone figures out what is going on with > lsof. draw gun, shoot foot. > >> For the case in AFS, it's a little weirder to be sharing such files >> across machines, but it's possible. > > i think the case of dso's is a reasonable argument for consistent (and > in this case unix/posix-like) behavior of unlinked files across clients. > oddly enough, if you are using emt you wont see this problem because of > the way it handled upgrades to programs/shared libs. possibly, just to > avoid this inconsistent behavior.
"it depends". we used emt and i promise you we had problems anyway, albeit not the one you're concerned about. it depends *how* you use emt. i came up with a means to cache dsos and when I left CMU that's what we were using. (i build a in collection x against so version 1.1 of library l in collection y; i upgrade collection y, and library l is now so version 2. so now i have a binary which won't run. solved by simply scanning every binary using ldd and caching every dependency, and then loading the collection of dsos at the lowest priority, so any *real* dso would always win over the cache) -- Derrick _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
