3 ms·

If you rm a file that someone else is reading, they can happily keep reading it for as long as they like. It's only when they close the file that the data becom

If you rm a file that someone else is reading, they can happily keep reading it for as long as they like. It's only when they close the file that the data becomes unavailable.

pjmlp 11y ago
I know how inodes work, thank you. My first UNIX was Xenix. Applications do crash when they make assumptions about those files. For example, when they are composed by multiple parts and give the filename for further processing via IPC, or have another instance generating a new file with the same name, instead of appending, because the old one is now gone. Another easy way to corrupt files is just to access them, without making use of flock, given its cooperative nature. I surely prefer the OSes that lock files properly, even if it means more work.
- zeveb 11y ago
  > For example, when they are composed by multiple parts and give the filename for further processing via IPC Of course, the proper way to do this in POSIX is to pass the filehandle. POSIX is actually a pretty cool standard; the sad thing is that one doesn't often see good examples of its capabilities being used to their full extent. For this, I primarily blame C: it's so verbose and has such limited facilities for abstraction that it's often difficult to see the forest for the trees. Combine that with a generation of folks whose knowledge of C dates back to a college course or four, in which efficient POSIX usage may not have been a concern, and one finds good, easy-to-read examples of POSIX harder to find than they really should be.
  - pjmlp 11y ago
    Unfortunately POSIX also shares the same implementation defined behaviour of C. I had my share of headaches when porting across UNIX systems. Also POSIX is now stagnated around support for CLI and daemon applications. There is hardly any updates for new hardware or server architectures. Actually, having used C compilers that only knew K&R, I would say POSIX is the part that should have been part of ANSI C, but they didn't want a large runtime tied to the language.

If you rm a file that someone else is reading, they can happily keep reading it for as long as they like. It's only when they close the file that the data becomes unavailable.

pjmlp 11y ago

I know how inodes work, thank you. My first UNIX was Xenix. Applications do crash when they make assumptions about those files. For example, when they are composed by multiple parts and give the filename for further processing via IPC, or have another instance generating a new file with the same name, instead of appending, because the old one is now gone. Another easy way to corrupt files is just to access them, without making use of flock, given its cooperative nature. I surely prefer the OSes that lock files properly, even if it means more work.

zeveb 11y ago
> For example, when they are composed by multiple parts and give the filename for further processing via IPC Of course, the proper way to do this in POSIX is to pass the filehandle. POSIX is actually a pretty cool standard; the sad thing is that one doesn't often see good examples of its capabilities being used to their full extent. For this, I primarily blame C: it's so verbose and has such limited facilities for abstraction that it's often difficult to see the forest for the trees. Combine that with a generation of folks whose knowledge of C dates back to a college course or four, in which efficient POSIX usage may not have been a concern, and one finds good, easy-to-read examples of POSIX harder to find than they really should be.
- pjmlp 11y ago
  Unfortunately POSIX also shares the same implementation defined behaviour of C. I had my share of headaches when porting across UNIX systems. Also POSIX is now stagnated around support for CLI and daemon applications. There is hardly any updates for new hardware or server architectures. Actually, having used C compilers that only knew K&R, I would say POSIX is the part that should have been part of ANSI C, but they didn't want a large runtime tied to the language.