Make MemoryRandomAccessFile handle the file being moved from under it #157
Conversation
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.)
|
Note to reviewers: I've made each of the individual commits logically distinct, so looking at the individual diffs for them might be easier. |
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.
|
Ping? (@dnfield ?) |
| FileNode node; | ||
| Exception deferredException; | ||
|
|
||
| // Resolve the backing immediately to ensure that the [FileNode] we write |
There was a problem hiding this comment.
We should probably check that the style is posix style here (see https://github.com/google/file.dart/blob/master/packages/file/lib/src/backends/memory/memory_file_system.dart#L46). I think it'd probably be fairly simple given that to implement the windows type behavior - wdyt?
There was a problem hiding this comment.
I agree that checking style would be a good way to configure the behavior. I don't think here would be the right place to do it. Windows typically wouldn't allow renaming/moving/deleting files with open handles in the first place, so I don't know what (if anything) we should do differently here. (I also currently don't have a Windows machine handy with Dart set up to verify dart:io's File's behavior there.)
There was a problem hiding this comment.
Do we have a bug tracking work on that?
There was a problem hiding this comment.
Not yet. I will file one.
Fix
MemoryRandomAccessFileto use only itsFileNodeand never thecorresponding
MemoryFile. While theMemoryRandomAccessFile(theequivalent of a file handle) is open, its
FileNodeshould neverchange, but the original
MemoryFilemight become backed by adifferent node if the file is moved, removed, or replaced.
POSIX systems typically allow this; Windows typically doesn't. For
now, make
MemoryFileSystemfollow the typical POSIX behavior. (Inthe long-term,
MemoryFileSystemperhaps should have configurablebehavior.)
Similarly, make
MemoryFile.openWrite'sIOSinkresolve theFileNodeimmediately instead of adding it to an async queue.Otherwise node resolution could return a different
FileNodethanwhat was originally intended.
Eagerly resolving the
FileNodehas the side-effect of potentiallythrowing exceptions earlier than expected. I therefore added a
mechanism to defer throwing.
Bonus:
FileSystemEntity.