Thomas,
On 6/14/22 13:52, Thomas Hoffmann (Speed4Trade GmbH) wrote:
Hello,
we are using Tomcat 10.0.16 under windows.
For sending files to the browser, we are using sendfile by setting the attribute
"org.apache.tomcat.sendfile.filename".
Streaming an image to the browser works well in this way.
But we observed that if the user tries to delete the file afterwards, there is
still a file-handle on this file.
Which user? Some admin on the server, or the user using the browser?
(Dumb question, I know, but tb and ff had a bug for a while where
downloads would leave dangling file handles, disallowing deleting those
files after they were downloaded.)
I took a look at NioEndpoint.java -->
https://github.com/apache/tomcat/blob/main/java/org/apache/tomcat/util/net/NioEndpoint.java
At line 869 there is a stream opened:
FileInputStream fis = new FileInputStream(f);
However, there is no close in this method. Maybe this might cause the open
file-handle?
Did you read the line above that?
@SuppressWarnings("resource") // Closed when channel is closed
FileInputStream fis = new FileInputStream(f);
The channel itself is cleaned-up properly and, with it, the file handle.
https://github.com/apache/tomcat/blob/69b9a3eeee41062dc1930782941bbaa1880e9281/java/org/apache/tomcat/util/net/NioEndpoint.java#L1226
(At least, I *think* this is where the cleanup happens. I'm not very
well-versed in the connection-handling code in Tomcat.)
We are using protocol="org.apache.coyote.http11.Http11NioProtocol".. I think
there are different implementations for sendfile-feature.
The open file-handle can be observer via ProcessExplorer from Microsoft.
How long did you wait for the file handle to close?
Are you able to attach a debugger and see that the object hasn't been
cleaned-up?
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
