On 25/03/2010 08:02, Claus Ibsen wrote:
Well the temp folder is there for a reason since its a temp folder. If
you want to keep stuff use a NON temp folder :)
That's just a joke isn't it - the folder C:\Temp is not %TMP% or %TEMP%;
there is nothing giving an application permission to delete its
contents; deleting files effecitvely at random can break other running
processes.
It's just plain bad.
Rant over.
If you want the funny side, at first I checked out the camel sourcecode
into C:\Temp - took me ages to work out why I'd got a self deleting
source tree :)
You are welcome to search the unit tests to see if you can find the
tests which may delete that folder.
Searching didn't find it, I ran the whole set of unit tests under
procmon and that found it: FileConsumerAbsoluteRootPathDefaultMoveTest.
I've created a jira for it:
https://issues.apache.org/activemq/browse/CAMEL-2578
Mind that its uses the Java temp folder as Unix machines uses /tmp
That's the problem, it doesn't, it just blindly assumes that it has the
right to delete and recreate "/temp" (hardcoded).
Anyway, I can provide a patch easily but I'm not sure what the test is
supposed to be testing.
The correct fix would be to base something off File.createTempFile(),
but is the test trying to validate that a path such as "/temp" works in
a platform agnostic way?
Note though that "/temp" won't work as a normal user on most linux
boxes, so I'd rather change it to use File.createTempFile().
Your call...
Jim
