Why Was: US Military Dead during Iraq War 1832

(jmfbahciv) writes:

It takes a bit of getting used to, I'll admit. But that's why the system call is named "unlink", rather than "delete", "remove", etc. The file is unlinked from the file system, but still exists. It's not actually deleted until no one is has it open anymore. In the meantime, it's possible to create another file of the same name; there's no conflict because the original one no longer exists as a named enbreasty.

BTW this gets around one of Windows' greatest pains in the butt (and probably the most FAd of Qs) - how do you update an executing program? Since Windows holds the .EXE file open while the program is running, the answer is "you can't" - followed by a description of various horrible kludges you have to use to work around this restriction. Under the Unix paradigm, on the other hand, copying in a new executable causes the old one to be unlinked - but still available for whatever purpose the OS might want it (do people still write programs with overlays?). From that point on, anyone who tries to execute the program gets the new version, even though the old one that's already running can do so to completion. No muss, no fuss.

I don't know. What do you mean by RESET? To us, "close" is a system call that means you're finished with the file. No further I-O calls for that file (file handle, actually) will be accepted.

No. If you create a new file, you get a new file. Creating a hard link is a distinct operation that isn't sneakily done behind your back.

Irrelevant; the inode is not restored, just the file's contents. When a file is restored (at least using the normal copy utility or file I-O functions), a new inode is created.

-- I'm really at ac.dekanfrus if you read it the right way. X Top-posted messages will probably be ignored. See RFC1855. HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!