[
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: [email protected]):
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.
