AbstractFileObject.delete(FileSelector) correctness relies on FilesCache
------------------------------------------------------------------------
Key: VFS-256
URL: https://issues.apache.org/jira/browse/VFS-256
Project: Commons VFS
Issue Type: Bug
Affects Versions: 2.0
Reporter: Marek Zawirski
Implementation of delete(FIleSelector) in AbstractFileObject uses findFiles()
to traverse files using DFS strategy - to find all files to remove, in
appropriate order. It guarantees that for each file, its children are removed
first. So, implementation of delete(FileSelector) iterates over DFS-ordered
list of files to remove and before removing each of it, checks whether it not
contain any children. That looks ok, at least if non-atomic check & delete is
meant to be achieved.
However, checking for file's children before file removal is made using
AbstractFileObject-level cached information about children. This information is
updated only if removed child found its parent in FileSystemManager cache and
fired parent's childrenChanged() method - see handleDelete(). If
FileSystemManager is configured to work, for example, with NullFilesCache,
removing any hierarchy of directories will *not* work, which is IMO incorrect
behavior.
So far, I see 2 easy fixes for that (can provide patches for these 2):
1) For each file file.getType().hasChildren(), refresh it before checking for
children number. May result in worse performance.
2) Record deleted files' names. Then, if some file being checked before removal
still has some children, check those children names - if they have been just
removed.
Any comments?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
