[ https://issues.apache.org/jira/browse/VFS-525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16375094#comment-16375094 ]
Otto Fowler commented on VFS-525: --------------------------------- {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(file); fm.start(); {code} This code is the correct method, I *think,* to monitor files the way you want to. This works with Local files, *and* with SFTP, but not with FTP. Those where the only three I tried. I think that accessing the file content may also have something to do with 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)