commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jean-Baptiste (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (VFS-528) DefaultFileMonitor missing to report some file creation.
Date Tue, 29 Jul 2014 21:08:39 GMT

     [ https://issues.apache.org/jira/browse/VFS-528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Jean-Baptiste updated VFS-528:
------------------------------

    Environment: Windows, Linux, x86, x86_64  (was: Windows)

> DefaultFileMonitor missing to report some file creation.
> --------------------------------------------------------
>
>                 Key: VFS-528
>                 URL: https://issues.apache.org/jira/browse/VFS-528
>             Project: Commons VFS
>          Issue Type: Bug
>    Affects Versions: 1.0, 1.1, 2.0, 2.1
>         Environment: Windows, Linux, x86, x86_64
>            Reporter: Jean-Baptiste
>
> It's hard to reproduce but sometimes the DefaultFileMonitor does not report some file
creation. It happens when a file is added in a directory that has just been added in the DefaultFileMonitor.
> It is more likely to appear when the DefaultFileMonitor is starting.
> To reproduce (might take several tries to fail)
> - Start the DefaultFileMonitor
> - Quickly create a directory inside the monitored directory.
> - Quickly create a file inside this directory.
> The issue is caused by a flaw in the code.
> When the new directory is detected, the DefaultFileMonitor fires the creation event as
expected (in fireAllCreate method). However does not immediately register the directory's
content for comparison with the next check. It rather postpones the registration with a call
to "queueAddFile(child)" (line 425).
> The directory and its content actually registered a bit later at the end of the main
loop on line 335.
> The issue is when a file is added between the queueAddFile and the actual addFile. No
events is fired for this file as it does not exists in the fireAllCreate method. But as it
gets registered a bit later, the next check don't detect any change on the file system and
does not trigger en event too.
> I see too possible fix for this issue:
> 1. Don't queue the registration of the file.
> 2. Make sure that when the actual registration occurs (the call to addFile), the exact
same set of files is used as in the fireAllCreate method.
> For my project I used the first solution by overriding the queueAddFile method. It made
me realized that it might be the reason why it is protected. It seems to work, but I'm not
sure if it as other consequences.
> The bug has been found on vfs 1.0 and 2.2.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message