I suppose it's not important since the exception is marked as INFORMATIONAL,
reassigning just to be sure.

No idea how to go about reproducing this. java.io.File.delete() just returns
false if deletion fails; there is no way to get details from the operating
system as to what is wrong. Perhaps the directory - or drive - was read-only at
the time; perhaps some other process had that file open; etc. Unless this is
known to happen to other people (only Win98?) I will have to close, I guess.

Thank you for your opinion. As I said in the query, it's not a problem for me, I
can live with it, and I don't mind if you close this query. I agree that it
could be only a win98 problem.

Here is my comment:
- it is not a question of read-only in file properties (I checked this and also
the parent folders)
- it happens systematically, each time I launch NetBeans, as sure as a
mathematical operation

I'll keep an eye on this query to see if you have any more questions.
Best respects.
ero.

The process that opened the file was the IDE itself. It actually mapped the file.
The problem is that the file was mmaped, then recognized as out of date and
about to be recreated.
java.nio has no way of explicit unmapping, and Windows can't delete the file
while mapped (ugh, every sane OS manages that correctly, yet windows is much
more prone to lost clusters...). In my experience, it was at least possible to
rename the file, but it seems Win98 fails even on that.

As a workaround, you can delete the file yourself, it will get recreated during
next startup and should stay that way (no more recreations during subsequent
startups) as long as you don't change the module set.

If we wanted to fix this, we'd have to special-case Win98 and create a
HeapByteBuffer instead.

I guess you're talking about the BinaryFS constructor. So there's no way to
close a mmap'd file except by GCing the MappedByteBuffer? That's awful!

Work-around seems to work well...
Thank very much you for your response, I don't need more.
At least we know now the cause of the problem!
ero.

*** Issue 64064 has been marked as a duplicate of this issue. ***

*** Issue 65091 has been marked as a duplicate of this issue. ***

*** Issue 64139 has been marked as a duplicate of this issue. ***

I'm wondering what a work-around might be for this?

I've seen the same behavior on WinXP when the IDE starts up and attempts to open
files in my users' roaming profiles.

Petr do you have some idea how to deal with this? I don't even know how to
reproduce it. It seems that you already put in the code which uses mmaped
buffers and which therefore renames, rather than deletes, the file, to work
around the Windows bug. (Is that filed for the JDK? Should use jdk_bug_NNNNNNN
in status whiteboard.) If this is really a GC problem, the only thing I can
think to do is insert

if (!renamed) {
    System.gc();
    renamed = cacheFile.renameTo(tmpFile); // try again
}

but I have no way of testing whether such a fix really works. I suspect it would
not be reliable. If it really worled, it would make startup a bit slower for
affected machines, but no exception at least.

If that doesn't work, we could consider creating alternate all-layers1.dat and
all-layers2.dat and permitting either to be used. (But what if both exist...?)
Or, if cleanupCache() when called from store() fails, just print the IOE message
to console as a warning, then pick a new cacheFile - meaning, I guess, that the
caching would not actually work, and startup would be longer.

Or, as you suggest, create an in-memory byte buffer. Problem is that you would
have to create it only conditionally, to avoid damaging performance on other
platforms, and I am not sure if just checking for "98" in the OS name is
reliable enough. Last comment suggests that other Windows machines can be
affected sometimes.

Jarda, try to look at this one. I thought the trick with renaming the file was
already in.

The renaming code is there from the beginning. The problem is that win98 won't
let you even rename an opened file.
The only occurence on non-w98 (issue 64064) seems to be more of a configuration
issue (special networked setup) that this actual problem.

If we could recognize w98, I'd go for HeapByteBuffer on that platform.

"#62247: Hoping to fix the problem for Windows98. #1 - we try a bit harder to 
GC the mmaped handle, #2 - if the rename files we still mark the file as 
delete on exit, so even if the exception is printed, next start should be ok" 
Checking in 
startup/src/org/netbeans/core/startup/layers/BinaryCacheManager.java; 
/cvs/core/startup/src/org/netbeans/core/startup/layers/BinaryCacheManager.java,v  
<--  BinaryCacheManager.java 
new revision: 1.2; previous revision: 1.1 
 

*** Issue 67798 has been marked as a duplicate of this issue. ***

*** Issue 71624 has been marked as a duplicate of this issue. ***

*** Issue 71873 has been marked as a duplicate of this issue. ***

*** Issue 72930 has been marked as a duplicate of this issue. ***