Jetty

DirectNIOBuffer does not release the file it is constructed from, consequently one cannot delete the file.

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Won't Fix
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: NIO
  • Labels:
    None
  • Number of attachments :
    0

Description

Path file = Paths.get("C:/Temp/my.test");
DirectNIOBuffer buffer = new DirectNIOBuffer(file.toFile());
Files.deleteIfExists(file);
// the Files.deleteIfExists throws the following exception
// java.nio.file.FileSystemException: C:\Temp\my.test: The process cannot access the file because it is being used by another process.
// at sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:86)
// at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97)
// at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102)
// at sun.nio.fs.WindowsFileSystemProvider.implDelete(WindowsFileSystemProvider.java:268)
// at sun.nio.fs.AbstractFileSystemProvider.deleteIfExists(AbstractFileSystemProvider.java:108)
// at java.nio.file.Files.deleteIfExists(Files.java:1110)
// at test.MyTest.run(MyTest.java:28)
// at test.MyTest.main(MyTest.java:41)

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Jan Bartel added a comment - - edited

Warren,

I think you'll find this a windows problem:
http://docs.codehaus.org/display/JETTY/Files+locked+on+Windows

See also this Sun bug:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4715154

Jan

Show
Jan Bartel added a comment - - edited Warren, I think you'll find this a windows problem: http://docs.codehaus.org/display/JETTY/Files+locked+on+Windows See also this Sun bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4715154 Jan
Hide
Permalink
Jan Bartel added a comment -

More like "Can't fix".

Jan

Show
Jan Bartel added a comment - More like "Can't fix". Jan
Hide
Permalink
Warren Goldman added a comment - - edited

This might be fixed, since the DirectNIOBuffer class simply by its' construction is leaving input streams open.

There are options;
1) provide a mechanism for the caller to cleanup after it,
2) have DirectNIOBuffer clean up after itself - I realize this is the most difficult
3) provide a constructor that accepts the input stream so the caller can take care of this, if needed

There are various options that could be pursued. Stating this is simply a windows issue, means this class is not really usable for those few of us that are actually using windows.

public DirectNIOBuffer(File file) throws IOException

{ super(READONLY,NON_VOLATILE); FileInputStream fis = new FileInputStream(file); FileChannel fc = fis.getChannel(); _buf = fc.map(FileChannel.MapMode.READ_ONLY, 0, file.length()); setGetIndex(0); setPutIndex((int)file.length()); _access=IMMUTABLE; }
Show
Warren Goldman added a comment - - edited This might be fixed, since the DirectNIOBuffer class simply by its' construction is leaving input streams open. There are options; 1) provide a mechanism for the caller to cleanup after it, 2) have DirectNIOBuffer clean up after itself - I realize this is the most difficult 3) provide a constructor that accepts the input stream so the caller can take care of this, if needed There are various options that could be pursued. Stating this is simply a windows issue, means this class is not really usable for those few of us that are actually using windows. public DirectNIOBuffer(File file) throws IOException { super(READONLY,NON_VOLATILE); FileInputStream fis = new FileInputStream(file); FileChannel fc = fis.getChannel(); _buf = fc.map(FileChannel.MapMode.READ_ONLY, 0, file.length()); setGetIndex(0); setPutIndex((int)file.length()); _access=IMMUTABLE; }
Hide
Permalink
Jan Bartel added a comment -

Warren,

Did you actually read the sun bug I pasted the link for??? In particular the evaluation:

We cannot fix this. Windows does not allow a mapped file to be deleted. This
problem should be ameliorated somewhat once we fix our garbage collectors to
deallocate direct buffers more promptly (see 4469299), but otherwise there's
nothing we can do about this.

Furthermore I draw your attention to the javadoc for the FileChannel class:

The buffer and the mapping that it represents will remain valid until the buffer itself is garbage-collected.
A mapping, once established, is not dependent upon the file channel that was used to create it. Closing the channel, in particular, has no effect upon the validity of the mapping.

If you would like to submit a workaround for the DirectNIOBuffer class, taking into account both of the above, we will take a look at it. I would also appreciate it if you would adopt a less aggressive tone to your posts.

Show
Jan Bartel added a comment - Warren, Did you actually read the sun bug I pasted the link for??? In particular the evaluation: We cannot fix this. Windows does not allow a mapped file to be deleted. This problem should be ameliorated somewhat once we fix our garbage collectors to deallocate direct buffers more promptly (see 4469299), but otherwise there's nothing we can do about this. Furthermore I draw your attention to the javadoc for the FileChannel class: The buffer and the mapping that it represents will remain valid until the buffer itself is garbage-collected. A mapping, once established, is not dependent upon the file channel that was used to create it. Closing the channel, in particular, has no effect upon the validity of the mapping. If you would like to submit a workaround for the DirectNIOBuffer class, taking into account both of the above, we will take a look at it. I would also appreciate it if you would adopt a less aggressive tone to your posts.
Hide
Permalink
Warren Goldman added a comment -

You are completely correct, my apologies for the tone.

Show
Warren Goldman added a comment - You are completely correct, my apologies for the tone.

People

  • Assignee:
    Jan Bartel
    Reporter:
    Warren Goldman
Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: