[
https://issues.apache.org/jira/browse/VFS-256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marek Zawirski updated VFS-256:
-------------------------------
Attachment: make_delete_safe_for_any_cache_v2.patch
make_delete_safe_for_any_cache_v1.patch
Two alternative patches proposal solving this issue - as described in issue's
description:
v1) [simpler, worse performance] before checking for children, refresh every
file with type that may have children
v2) [slightly more complex, better performance] remember set of names of
deleted files; during checking for children compare returned children to this
set
3rd alternative may be to try find out parent of deleted file in
files_to_delete and force childrenChanged() on it if necessary. But it seems to
even more complex.
I am looking forward for some comments.
> 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
> Attachments: make_delete_safe_for_any_cache_v1.patch,
> make_delete_safe_for_any_cache_v2.patch
>
>
> 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.
