The file system indexes are left in an inconsistent state after the move. This doesn't happen if the sample application is modified not to close and re-open (Files.newFileSystem) the file system OR if we flush (close and re-open) the file system, move and the flush the file system again. We can make a couple of changes to ZipFileSystem.update method to allieviate the problem. But these raise one or two deeper questions, which require further analysis of the file move flow.
two modifications can be made to solve this problem.
these are to the
update and updateDelete / removeFromTree.
Both of these work fine without modification if the move update
is performed on a ZFS which has not been closed, and synced to disk.
When the filesystem has been closed and written to disk, and then
"re-open" (i.e. newFileSystem is invoked on FileSystems) the
reconstituted ZFS has a slightly different representation in memory.
Thus update has to take into account that the update Entry object might be a COPY
(not just NEW or FILECH)
and the updateDelete/removeFromTree has to allow for the fact that the IndexNodes being
compared may not refer to same object instance, but may refer to a copy returned from the
CEN, as per the getEntry0 method, as such it requires to invoke equals rather than ==.
The key question then is:
"why is the IndexNode an instance of Entry when the ZFS is newly created and
manipulated in memory without being written to disk, while this is not the
case when the ZFS is closed, written to disk and the re-opened ?"
We'd need to defer to the designer Xueming Shen, with respect to this.