commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ralph Goers (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (VFS-238) DefaultFileMonitor fails to notice file creations, or re-creations
Date Thu, 12 Mar 2009 00:06:50 GMT

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

Ralph Goers edited comment on VFS-238 at 3/11/09 5:06 PM:
----------------------------------------------------------

I created a unit test for this and it passes in all of these cases with a couple of caveats

1. monitor.addFile() must be called after the file is deleted for the recreate to be detected.
The file is automatically removed from the listener when the file is deleted. Whether this
is "correct" or not, it is working as designed.
2. Some events are very time sensitive. Due to polling intervals and the timestamp only being
guaranteed to the second if things happen too quickly the events may not be detected. Additionally,
when the file is deleted there is a bit of a delay before the listener is removed, so if monitor.addFile
is called too quickly it may not result in the listener being readded.

Take a look at DefaultFileMonitorTests in trunk.

Because the monitor uses polling I'm not sure there is much that can be done about the timing
issues.

      was (Author: ralph.goers@dslextreme.com):
    I created a unit test for this and it passes in all of these cases with a couple of caveats

1. monitor.addFile() must be called after the file is deleted for the recreate to be detected.
The file is automatically removed from the listener when the file is deleted. Whether this
is "correct" or not, it is working as designed.
2. Some events are very time sensitive. Due to polling intervals and the timestamp only being
guaranteed to the second if things happen too quickly the events may not be detected. Additionally,
when the file is deleted there is a bit of a delay before the listener is removed, so if monitor.addFile
is called to quickly it may not result in the listener being readded.
  
> DefaultFileMonitor fails to notice file creations, or re-creations
> ------------------------------------------------------------------
>
>                 Key: VFS-238
>                 URL: https://issues.apache.org/jira/browse/VFS-238
>             Project: Commons VFS
>          Issue Type: Bug
>    Affects Versions: 1.0
>         Environment: linux, amd64 (ubuntu 8.10)
>            Reporter: Andy Brook
>
> As title, 
> {code}
> 		FileSystemManager fsManager = VFS.getManager();
> 		FileObject listendir = fsManager.resolveFile("/tmp/test.txt");
> 		
> 		fFileMonitor = new DefaultFileMonitor(new MailboxFileListener(this)); 
> 		fFileMonitor.setRecursive(true); 
> 		fFileMonitor.addFile(listendir);
> 		fFileMonitor.start(); 
> {code}
> h3. Uncreated initial state
> # If the file does not exist before the above is run, no 'create' even is fired when
it is subsequently created.
> h3. Recreation use-case
> # If 'test.txt' exists, notifications of updates are generated as expected.  
> # If I now remove the file, I get a delete notification - as expected
> # If I now re-create the file, I get no notifications, even if updating.
> So this kind of breaks for me, the same behaviour was in the maven 2005.. jars.
> Am I misunderstanding what the DefaultFileMonitor is supposed to do?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message