4 ms·

This is easy, actually. File and it's directory entry are two separate things. So you can remove and replace open file, but the old handle will still point to

This is easy, actually. File and it's directory entry are two separate things. So you can remove and replace open file, but the old handle will still point to the old file - it just won't be open-able using the original filename. Once all the processes will close the handle to the old file, and no directory entry points to it, it will be removed from the file system.

SketchySeaBeast 7y ago
What happens if the user tries to save the stale file? They have to give it a new name?
- pjc50 7y ago
  Default UNIX semantics: you don't actually know this has happened to a file you're using on most filesystems, so you can continue writing to it and it will vanish on close. Many programs do the "write to temp file and rename on top of old file" trick, which is almost-atomic, and you can have multiple programs doing that to the same file at the same time without noticing. (If you're on NFS writing to a deleted inode may do something different and probably broken)
  - 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 ago
      Yes, it's very dangerous. Files in Unix-style systems can have invisibly shared mutable state. Like having shared memory without any mutexes.
    - vetinari 7y ago
      That 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 ago
      Noncooperative 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)

SketchySeaBeast 7y ago

What happens if the user tries to save the stale file? They have to give it a new name?

pjc50 7y ago
Default UNIX semantics: you don't actually know this has happened to a file you're using on most filesystems, so you can continue writing to it and it will vanish on close. Many programs do the "write to temp file and rename on top of old file" trick, which is almost-atomic, and you can have multiple programs doing that to the same file at the same time without noticing. (If you're on NFS writing to a deleted inode may do something different and probably broken)
- 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 ago
    Yes, it's very dangerous. Files in Unix-style systems can have invisibly shared mutable state. Like having shared memory without any mutexes.
  - vetinari 7y ago
    That 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 ago
    Noncooperative 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)