Nicolas Alvarez wrote:
> fuser and lsof can tell you what programs currently have a certain file 
> open. 

There is that, yes.

> Probably it's race-condition-prone. Probably theu work by walking 
> through /proc and parsing it.

""" Since lsof reads kernel memory in its  search  for  open  files,  rapid 
changes in kernel memory may produce unpredictable results."""

I.e., it works like "ps" used to before /proc.  And yes, it looks like it 
would be race-condition prone. But probably good enough, really.

Lacking a transactional capability is also problematic.  If you get half way 
through the upgrade of something and your program or even system crashes, 
you could be screwed, especially if what got corrupted was important to 
getting the system running again. I'm not sure if Linux has transactional 
file systems in common use. But again, that's off topic to the original 
"Windows locks executables" rant and more onto "mainframes actually worried 
about this crap."  Or more precisely, people actually worry about this crap 
when a crash costs actual real large amounts of money per second of downtime.

> If a shared library is ABI-incompatible, it will have a different soname, 
> which means it will have a different *filename* too. Programs linked to the 
> old version of the library won't be *able* to load the new version, and 
> viceversa.

That's a point, yes. Assuming you manage to avoid DLL Hell.

> Or don't break the compatibility to begin with ;)

Such is rarely done on purpose, yes.

-- 
Darren New, San Diego CA, USA (PST)
   Forget "focus follows mouse." When do
   I get "focus follows gaze"?

Post a reply to this message