1. 12 Dec, 2023 4 commits
  2. 08 Dec, 2022 1 commit
  3. 01 Dec, 2022 1 commit
  4. 10 May, 2021 1 commit
  5. 01 Mar, 2021 3 commits
  6. 28 Feb, 2021 10 commits
  7. 26 Feb, 2021 3 commits
  8. 15 Sep, 2020 1 commit
  9. 01 Sep, 2020 1 commit
  10. 17 Dec, 2019 1 commit
  11. 31 Oct, 2019 6 commits
  12. 28 Sep, 2019 1 commit
  13. 26 Sep, 2019 3 commits
  14. 22 Sep, 2019 4 commits
    • Geoff Simmons's avatar
    • Geoff Simmons's avatar
      Add the "File deletion and file updates" section. · e4e31613
      Geoff Simmons authored
      And update related parts of the docs.
    • Geoff Simmons's avatar
      Add reader.deleted(). · 613201e9
      Geoff Simmons authored
    • Geoff Simmons's avatar
      Re-consider part of the concept, and refactor some code. · ba5ecac5
      Geoff Simmons authored
      POSIX requires that a file description is referenced by mmap(2),
      so the refcount does not reach 0 when the file is deleted while
      it is still mapped. So POSIX-compliant systems can be expected to
      retain the mapping after file deletion.
      Unless the VMOD goes to the trouble of copying the file, the safe
      way to update it is to delete it, then write a file with the same
      name with the new contents. A check may happen to run between
      deletion and the new write. But because of the property mentioned
      above, this is not a real problem for memory-mapped files.
      So the VMOD will work according to these rules:
      - If a check cannot read a file due to ENOENT, it is not an error.
        (It is an error if the file does not exist on initial read.)
        In that case, the file is considered unchanged -- the current
        mapping continues as the cached file contents.
      - This means that for the VMOD, a deleted file is *not* considered
        to be in error, provided it could be read initially (that is, it is
        already mapped).
      - We set a flag when the file is deleted, so that the condition
        can be detected.
      - Users are advised in the docs that the "delete, then write"
        procedure is the *only* method for updating the file that the
        VMOD supports. Other methods may work, some of the time, but
        you do it differently at your own risk.
      Also, access(2) is not a reliable means to determine if the file
      can be read and mapped, because if checks permissions against
      the real UID/GID, whereas open(2) depends on effective UID/GID.
      - checks begin with open(2), then use fstat(2) for the stat check.
      - Path searches are done by attempting open(2) with the filename
        on each directory in the path.