[
https://issues.apache.org/jira/browse/VFS-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16375025#comment-16375025
]
Otto Fowler edited comment on VFS-525 at 2/23/18 10:34 PM:
-----------------------------------------------------------
OK,
This is working as designed. It only *seems* broken when you do not consider
the DefaultFileMonitor:
{code:java}
DefaultFileMonitor fm = new DefaultFileMonitor(new FileListener() {
@Override
public void fileDeleted(FileChangeEvent event) throws Exception
{
System.out.println(event.getFile().getName().getPath()+"
Deleted.");
}
@Override
public void fileCreated(FileChangeEvent event) throws Exception
{
System.out.println(event.getFile().getName().getPath()+"
Created.");
}
@Override
public void fileChanged(FileChangeEvent event) throws Exception
{
System.out.println(event.getFile().getName().getPath()+"
Changed.");
}
});
fm.setRecursive(true);
fm.addFile(listendir);
fm.start();
{code}
In other words, if you want to monitor for changes external to VFS you need to
use this.
BUT: the FTP provider, because it is written to speed up access is implemented
in such a way that the monitor doesn't work.
was (Author: ottobackwards):
OK,
This is working as designed. It only *seems* broken when you do not consider
the DefaultFileMonitor:
{code:java}
DefaultFileMonitor fm = new DefaultFileMonitor(new FileListener() {
@Override
public void fileDeleted(FileChangeEvent event) throws Exception
{
System.out.println(event.getFile().getName().getPath()+"
Deleted.");
}
@Override
public void fileCreated(FileChangeEvent event) throws Exception
{
System.out.println(event.getFile().getName().getPath()+"
Created.");
}
@Override
public void fileChanged(FileChangeEvent event) throws Exception
{
System.out.println(event.getFile().getName().getPath()+"
Changed.");
}
});
fm.setRecursive(true);
fm.addFile(listendir);
fm.start();
{code}
In other words, if you want to monitor for changes external to VFS you need to
use this.
> FtpFileObject.exists() output not impacted by refresh() after file deletion
> ---------------------------------------------------------------------------
>
> Key: VFS-525
> URL: https://issues.apache.org/jira/browse/VFS-525
> Project: Commons VFS
> Issue Type: Bug
> Affects Versions: 2.0
> Environment: Windows 7 [Version 6.1.7601]
> java version "1.6.0_31"
> Java(TM) SE Runtime Environment (build 1.6.0_31-b05)
> Java HotSpot(TM) Client VM (build 20.6-b01, mixed mode, sharing)
> commonc vfs 2.0
> commons net 3.3
> Reporter: Volker Bergmann
> Priority: Critical
> Labels: FTP,, cache, exists
>
> Context: I store a file in an FTP directory and poll the FTP file (using
> FtpFileObject.exists()) until it is imported by another system and deleted on
> the FTP folder.
> Issue: On the first lookup, the file is present and FtpFileObject.exists()
> returns true correctly. That's OK, but after the file has been deleted,
> FtpFileObject.exists() continues to return true, even when using
> CacheStrategy.MANUAL and calling FtpFileObject.refresh().
> Observations: Upon refresh() there is a complex interaction between the file
> and parent folder object as well as the code of AbstractFileObject and
> FtpFileObject. The issue seems to stem from the fact that for the existence
> check of a file, its parent file object is queried for its #children
> attribute which caches the child entries. On the one hand, the child file
> seems to clear the link to the parent folder, causing a detach() of the
> parent, but since the parent folder already is in detached state, it does not
> clear its #children attribute.
> By the way: I consider it a poor inheritance design if a child class
> attribute
> FtpFileObject: private Map<String, FTPFile> children
> shadows a parent class attribute
> AbstractFileObject: private FileName[] children
> At least it makes debugging more cumbersome.
> Workaround: The issue stems from the fact that the parent FtpFileObject is
> not cleared correctly because attached==false. Thus I use a call to the
> parent's getType() method which causes an attach() and, finally, attached==
> true and then call refresh() on the parent and the child:
> // This is a workaround for VFS 2.0's flaws in the
> // handling of attached/detached state and caching:
> FileObject parent = file.getParent();
> parent.getType(); // assure that parent folder is attached
> parent.refresh(); // detach parent folder and clear child object cache
> // (works only if attached before)
> // ...end of workaround
> file.refresh();
> System.out.println("File.exists(): {}", file.exists());
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)