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

Otto Fowler commented on VFS-525:
---------------------------------

These tests illustrate the issue.

I believe they will both fail as written.  The first one certainly does.  
Interestingly, if they are run in the same test file, the second one will fail 
in setup.  This is because the bug also causes the test prep to fail trying to 
delete the existing files for a clean test, and it still thinks the deleted 
'a.txt' exists and tried to delete it.  Kind of funny.

 
{code:java}
public void testDetectFileDoesNotExistAfterExternalDelete() throws Exception {
    final FileObject scratchFolder = createScratchFolder();

    final FileObject file = scratchFolder.resolveFile("dir1/a.txt");

    // use canonical file to delete
    File testDirFile = getTestDirectoryFile();
    File writeDirFile = new File(testDirFile,"write-tests");
    File dir1File = new File(writeDirFile,"dir1");
    File fileUnderTest = new File(dir1File,"a.txt");
    assertTrue(file.exists());

    fileUnderTest.delete();
    assertFalse(fileUnderTest.exists());

    file.refresh();
    assertFalse(file.exists());
    scratchFolder.close();
    file.close();
}


public void testDetectExternalChangeInFileSizeAfterExternalMod() throws 
Exception {
    final FileObject scratchFolder = createScratchFolder();

    final FileObject file = scratchFolder.resolveFile("dir2/b.txt");

    // use canonical file to delete
    File testDirFile = getTestDirectoryFile();
    File writeDirFile = new File(testDirFile,"write-tests");
    File dir1File = new File(writeDirFile,"dir2");
    File fileUnderTest = new File(dir1File,"b.txt");
    assertTrue(file.exists());
    long size = file.getContent().getSize();
    long oldFileSize = fileUnderTest.length();
    assertEquals(size,oldFileSize);
    try (FileOutputStream fileOutputStream = new 
FileOutputStream(fileUnderTest)) {
        fileOutputStream.write("Addition".getBytes());
        fileOutputStream.flush();
    }
    long newFileSize = fileUnderTest.length();
    assertFalse(newFileSize == oldFileSize);
    file.refresh();
    assertEquals(newFileSize,file.getContent().getSize());
}
{code}
 

I am not sure I can sum up the issues.  But the caching vs. getting current 
data is broken fundamentally.

 

 

 

> 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)

Reply via email to