You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In #157, I made MemoryFile/MemoryRandomAccessFile try to handle the file being renamed/moved/removed from under them. Currently they always follow POSIX behavior (the equivalent of the open file handle tracks the equivalent of the inode), which is consistent with how dart:ioFile behaves on POSIX systems.
I have not verified what happens on Windows systems, but I expect that rename/move/remove operations on dart:io's File will fail with an exception if they're attempted on files with open handles. If so, MemoryFile should follow the behavior and
would need to keep track of openRead/openWrite/open/openAsync calls (and determine when the corresponding Stream/IOSink/MemoryRandomAccessFile is closed) and disallow the file from being renamed/moved/removed. (For completeness I think we'd also need to prevent such operations on all parent directories too.)
Since one might want to test behavior for a platform other what a test is running on, @dnfield suggested that we could make the behavior configurable based on the FileSystemStyle.
The text was updated successfully, but these errors were encountered:
In #157, I made
MemoryFile
/MemoryRandomAccessFile
try to handle the file being renamed/moved/removed from under them. Currently they always follow POSIX behavior (the equivalent of the open file handle tracks the equivalent of the inode), which is consistent with howdart:io
File
behaves on POSIX systems.I have not verified what happens on Windows systems, but I expect that rename/move/remove operations on
dart:io
'sFile
will fail with an exception if they're attempted on files with open handles. If so,MemoryFile
should follow the behavior andwould need to keep track of
openRead
/openWrite
/open
/openAsync
calls (and determine when the correspondingStream
/IOSink
/MemoryRandomAccessFile
is closed) and disallow the file from being renamed/moved/removed. (For completeness I think we'd also need to prevent such operations on all parent directories too.)Since one might want to test behavior for a platform other what a test is running on, @dnfield suggested that we could make the behavior configurable based on the
FileSystemStyle
.The text was updated successfully, but these errors were encountered: