commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Otto Fowler (JIRA)" <>
Subject [jira] [Commented] (VFS-525) FtpFileObject.exists() output not impacted by refresh() after file deletion
Date Wed, 21 Feb 2018 03:34:00 GMT


Otto Fowler commented on VFS-525:

VFS-210 broke this, when it removed the call to getInfo(true) in refresh().

 * @throws FileSystemException if an error occurs.
public void refresh() throws FileSystemException {
    if (!inRefresh) {
        try {
            inRefresh = true;

            synchronized (getFileSystem()) {
                this.fileInfo = null;

             * VFS-210 try { // this will tell the parent to recreate its children collection
getInfo(true); } catch
             * (IOException e) { throw new FileSystemException(e); }
        } finally {
            inRefresh = false;


> FtpFileObject.exists() output not impacted by refresh() after file deletion
> ---------------------------------------------------------------------------
>                 Key: VFS-525
>                 URL:
>             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

View raw message