tree 3bb1f81b5790d1f81625ccc661e776e71ecfc842
parent c49d032a947805a9d41ea9d836698dc52b4ac137
author James D. Lin <jamesderlin@users.noreply.github.com> 1593644179 -0700
committer GitHub <noreply@github.com> 1593644179 -0700
gpgsig -----BEGIN PGP SIGNATURE-----
 
 wsBcBAABCAAQBQJe/RSTCRBK7hj4Ov3rIwAAdHIIAGT6WsbiwFU4fM2/4Bdw8aAR
 r5NsxznY1Ky++RYJTGUxoiRJILxJojQgIUSfFccTiurfDZq0HMdD8p8dY5j2qZb7
 SkPapc475qKALnTvyFrv8Fb4weL2QdhEPW5x/XG4CxIJgXlifXdKMvfI7jdV/H34
 Lx4+5Rsq67cAfHuJ+6p0XDuclzZBI+ayDpMYJEiWiwv7CtE/GB5vA0mArac4V4ek
 e1sOm8XrJ6VRO9TiQf+KmO0T70JhSrFH8kAgiTNlZJDuJspFP8xaOWK8Ph85vuAz
 AzbRUma0bzmivTTRrU57pGmMeMS0YXtbrIxjSm7/br5LCf+megW5VXuoPYLofHg=
 =TKEK
 -----END PGP SIGNATURE-----
 

Make MemoryRandomAccessFile handle the file being moved from under it (#157)

* Make rename tests verify the path of the returned FileSystemEntity

* Add explicit types to fix analysis lints

* Make MemoryRandomAccessFile handle the file being moved from under it

Fix `MemoryRandomAccessFile` to use only its `FileNode` and never the
corresponding `MemoryFile`.  While the `MemoryRandomAccessFile` (the
equivalent of a file handle) is open, its `FileNode` should never
change, but the original `MemoryFile` might become backed by a
different node if the file is moved, removed, or replaced.

POSIX systems typically allow this; Windows typically doesn't.  For
now, make `MemoryFileSystem` follow the typical POSIX behavior. (In
the long-term, `MemoryFileSystem` perhaps should have configurable
behavior.)

* Make MemoryFile.openWrite better handle a file being moved from under it

Make `MemoryFile.openWrite`'s `IOSink` resolve the `FileNode`
immediately instead of adding it to an async queue.  Otherwise node
resolution could return a different `FileNode` than what was
originally intended.

Eagerly resolving the `FileNode` has the side-effect of potentially
throwing exceptions earlier than expected.  I therefore added a
mechanism to defer throwing.