Mailing-List: contact user-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Users List" <user@commons.apache.org>
Received-SPF: pass (nike.apache.org: local policy)
Content-Type: multipart/alternative;
 boundary="========GMXBoundary139681342533205331133"
Date: Tue, 17 Jul 2012 09:53:25 -0400
From: "Laurent van Roy" <laurent.vanroy@iname.com>
Message-ID: <20120717135325.139680@gmx.com>
MIME-Version: 1.0
Subject: [IO FILE MONITOR]Interferences between monitor and files alterations
To: user@commons.apache.org

--========GMXBoundary139681342533205331133
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit

Hello,

 I've developped a little program dealing with Folder reading and manipulation.
 It has been built in two parts: a library dealing with the folders manipulations and a library with the GUI (Swing).

 I implemented a File Monitor piece to catch manual folder manipulations done outside of the application.

 When I implemented it, some of the JUnit tests of the folder manipulation library went wrong: some folders couldn't be deleted, some couldn't be renamed.
 => solution: before making the manipulations: I suspend the file monitor with monitor.stop() and later with a monitor.start().

 This worked fine and smoothly with my JUnits tests.

 Now I do the same through the GUI. And the monitor.stop() takes a huge among of time: * around 45s*.
 Rem: the monitor.stop() was called in Swing's EventDispatchThread. I extracted it from there. It didn't change anything.

 So, I'm back to the root problem: interference between the file monitor and the folder manipulations:
 So my questions are :
 1) Is it possible to avoid these interferences ?
 2) If no, is there another way to suspend the monitor, other than stop/start ?
 3) if no, is it possible to avoid the huge amount of time taken by the stop() when called from the GUI ?

 Kind Regards,

 Laurent

--========GMXBoundary139681342533205331133--