commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marek Zawirski (JIRA)" <>
Subject [jira] Created: (VFS-256) AbstractFileObject.delete(FileSelector) correctness relies on FilesCache
Date Fri, 15 May 2009 12:56:45 GMT
AbstractFileObject.delete(FileSelector) correctness relies on FilesCache

                 Key: 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.

View raw message