I think the problem is that there is a stream opened on that file when the delete is called. So the file is locked and the delete fail. Under linux you can remove an opened file because it is really removed but the one that is reading it still keep an handle to the file and the stream is still valid. The file is finally removed when you close every stream for that file.
I agree this is a bug but we had this in ALL versions of James and we can't block 2.3 for this as we are in RC and this bug has always been there. Furthermore, even if I think I know a few places where to look to fix this problem I currenlty have no time to work on this. So this have to wait at least 4 weeks if no one else works on this. Stefano Vincenzo Gianferrari Pini wrote: > I too could reproduce the issue with current 2.3rc1 (not tried with current > trunk). > > The problem occurs *only* under Windows, as a very similar configuration > under linux (at least with same repositories structure) works fine. > > Using a debugger I found that command "file.delete();" at line 277 of > AbstracFileRepository fails (returns false) *because the > XXX.Repository.FileStreamStore file is locked by Windows*, while the > XXX.Repository.FileStreamStore file is not and because of that it is > successfully deleted. > > The XXX.Repository.FileStreamStore probably is flushed but not closed when > created into the spool, and there may be a difference in behaviour between > Windows and Linux. We should investigate further. > > This is a major bug. > > Vincenzo --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
