4 ms·
Doesn't that end up being dangerous as far as updates? You keep blowing away the file? I think part of my problem is I'm visualizing this as a shared file bein
by SketchySeaBeast 7y ago
Doesn't that end up being dangerous as far as updates? You keep blowing away the file?
I think part of my problem is I'm visualizing this as a shared file being updated by users, and not, say, system updates. System updates make sense - we can assume only the system will be modifying them, and it'll be relatively low touch, but I keep visualizing a shared text document.
- SAI_Peregrinus 7y agoYes, it's very dangerous. Files in Unix-style systems can have invisibly shared mutable state. Like having shared memory without any mutexes.
- vetinari 7y agoThat opens an entirely new can of worms, called "file locking & unix". Usually these multiple processes have some agreed way to take their turn on writing; or they use library like sqlite (or berkeley db in the past), that library brings that mutually-agreed locking mechanism with it.
- pjc50 7y agoNoncooperative shared text documents only kind of work at the user level like in notepad++ or vscode where it keeps an eye on the timestamp and offers to lose either the edits in memory or the edits on disk. Inserting things into the middle can't be done without rewriting everything after. The only thing that does work with shared writing is logiles with O_APPEND, where multiple processes can safely add to the end of a file. (For historical examples of this, have a look at mbox locking versus maildir; the "mbox" format is basically keeping all your email as a huge text file, and locking protocols have developed around that so multiple mail clients can coexists without wrecking it)