commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "neeraj singh chauhan (JIRA)" <>
Subject [jira] [Commented] (VFS-528) DefaultFileMonitor missing to report some file creation.
Date Mon, 01 Sep 2014 08:34:23 GMT


neeraj singh chauhan commented on VFS-528:

Hi Jean,

Thanks for the update.
I tried this also, but unfortunately the result is the same for me i.e. no event is being
generated for few file creations.

I am doing following:
1. At the end of every hour, downloading some files to a particular directory (created at
00:00 HRS) being monitored by file listener. In other words, this task is being performed
24 times a day in the same directory which gets created at 00:00 HRS.
2. Additionally, as soon as the file download completes, I am renaming the downloaded file
with a name appended with the timestamp (YYYYMMDD).
3. As per expectation I should get two file creation events associated with ever file I download
i.e. first for file creation by download and second for file creation by rename.
4. For most of the files, I am getting proper events (i.e. after file download and after file
5. For few files I am just getting the file creation event after download and not after rename.
As per observation, this is happening for first hour of the day only i.e. 00:00 HR.


> DefaultFileMonitor missing to report some file creation.
> --------------------------------------------------------
>                 Key: VFS-528
>                 URL:
>             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

View raw message