[ 
https://issues.apache.org/jira/browse/VFS-634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16302035#comment-16302035
 ] 

Bernd Eckenfels commented on VFS-634:
-------------------------------------

I found out what the reaso is, but nut sure how to fix it best:

- when the manager is closed it will start by closing and removing all file 
providers (including "file").
- Then it will close the fileReplicator and temporaryFileStore. Both have a 
list of `File` objects which it wants to remove and therefore invokes 
`context.toFileObject()` on those.
- This will trigger parsing of the name via the still remembered existing 
DefaultLocalFileProvider.findFile.
- This will invoke DefaultFileSystemManager.resolveName, but this does not find 
the FileProvider for the file scheme anymore.
- Therefore it does fails through to the defaultProvider.parseURI which does 
basically work, however it decides that C: is not a slash-terminated URL and 
therefore declares it file.
- On the next findFilesystem it will insert a new file: filesystem with a 
broken root file (missing C: as it called getParent() on it)
- with that broken filesystem the shown exception is generated
- the exception does not actually list the rootURIs it actually compared

One option is to close the file replicator before the fileproviders. However 
this might lead to a unclear shutdown if some threads still resolve files.

Another option would be to not close/remove the file provider or add it after 
the providers are cleared:

        providers.clear();
        providers.put("file", localFileProvider);

this does work as well, has less impact on the rest of the code but is also not 
very clear.

A last option would be to make the replicant delete the java File objects 
without the help of VFS. They are already stored as file objects so this is not 
a big abstraction leak (but it does require to code some recursive delete it 
seems).

Any ideas?

I guess we also need to add a close() test which mocks the logger and verifies 
we dont get new warnings.


> DefaultFileReplicator fails to clean all local files on close()
> ---------------------------------------------------------------
>
>                 Key: VFS-634
>                 URL: https://issues.apache.org/jira/browse/VFS-634
>             Project: Commons VFS
>          Issue Type: Bug
>    Affects Versions: 2.1
>         Environment: windows
>            Reporter: Gilian HALOUIN
>
> Hi,
> We face an issue when we use the DefaultFileSystemManager.
> With this example :
> {code:java}
> import org.apache.commons.vfs2.FileObject;
> import org.apache.commons.vfs2.FileSystemException;
> import org.apache.commons.vfs2.Selectors;
> import org.apache.commons.vfs2.VFS;
> import org.apache.commons.vfs2.impl.DefaultFileSystemManager;
> /**
>  * @author GHALOUIN
>  *
>  */
> public class TestVFS {
>     /**
>      * @param args
>      * @throws FileSystemException
>      */
>     public static void main(final String[] args) throws FileSystemException {
>         final DefaultFileSystemManager vfsManager = 
> (DefaultFileSystemManager) VFS.getManager();
>         final FileObject tempDir = vfsManager.resolveFile("tmp://simulation");
>         final FileObject fileSrc = vfsManager.resolveFile("C:/toto.txt");
>         tempDir.resolveFile("toto").copyFrom(fileSrc, Selectors.SELECT_SELF);
>         vfsManager.close();
>     }
> }
> {code}
> At the close call we have the following error :
> INFOS: Using "C:\Users\ghalouin\AppData\Local\Temp\vfs_cache" as temporary 
> files store.
> avr. 21, 2017 4:21:27 PM 
> org.apache.commons.vfs2.impl.StandardFileSystemManager warn
> AVERTISSEMENT: Could not clean up temporary file "tmp_382_tempfs".
> org.apache.commons.vfs2.FileSystemException: Incorrect file system URI 
> "file:///C:/" in name 
> "file:///C:/Users/ghalouin/AppData/Local/Temp/vfs_cache/tmp_382_tempfs", was 
> expecting "file:///C:".
>       at 
> org.apache.commons.vfs2.provider.AbstractFileSystem.resolveFile(AbstractFileSystem.java:324)
>       at 
> org.apache.commons.vfs2.provider.AbstractFileSystem.resolveFile(AbstractFileSystem.java:317)
>       at 
> org.apache.commons.vfs2.provider.AbstractOriginatingFileProvider.findFile(AbstractOriginatingFileProvider.java:84)
>       at 
> org.apache.commons.vfs2.provider.local.DefaultLocalFileProvider.findLocalFile(DefaultLocalFileProvider.java:106)
>       at 
> org.apache.commons.vfs2.provider.local.DefaultLocalFileProvider.findLocalFile(DefaultLocalFileProvider.java:119)
>       at 
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.toFileObject(DefaultFileSystemManager.java:1003)
>       at 
> org.apache.commons.vfs2.impl.DefaultVfsComponentContext.toFileObject(DefaultVfsComponentContext.java:78)
>       at 
> org.apache.commons.vfs2.impl.DefaultFileReplicator.deleteFile(DefaultFileReplicator.java:172)
>       at 
> org.apache.commons.vfs2.impl.DefaultFileReplicator.close(DefaultFileReplicator.java:111)
>       at 
> org.apache.commons.vfs2.impl.PrivilegedFileReplicator$CloseAction.run(PrivilegedFileReplicator.java:195)
>       at java.security.AccessController.doPrivileged(Native Method)
>       at 
> org.apache.commons.vfs2.impl.PrivilegedFileReplicator.close(PrivilegedFileReplicator.java:113)
>       at 
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.closeComponent(DefaultFileSystemManager.java:500)
>       at 
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.close(DefaultFileSystemManager.java:604)
>       at testVFS.TestVFS.main(TestVFS.java:29)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Reply via email to