New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Resources: closing outputstream bug, recursive delete #1176
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -228,13 +228,16 @@ public OutputStream out() { | |
@Override | ||
public void close() throws IOException { | ||
delegate.close(); | ||
Lock lock = lock(); | ||
try { | ||
// no errors, overwrite the original file | ||
Files.move(temp, actualFile); | ||
} | ||
finally { | ||
lock.release(); | ||
//if already closed, there should be no exception (see spec Closeable) | ||
if (temp.exists()) { | ||
Lock lock = lock(); | ||
try { | ||
// no errors, overwrite the original file | ||
Files.move(temp, actualFile); | ||
} | ||
finally { | ||
lock.release(); | ||
} | ||
} | ||
} | ||
|
||
|
@@ -429,7 +432,7 @@ public String toString() { | |
|
||
@Override | ||
public boolean delete() { | ||
return file.delete(); | ||
return file.exists() && Files.delete(file); | ||
} | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Not sure about this one, the functionality was isolated into the Resources class - specifically so implementors (like you) would have less work to do when implementing a Resource. See: That functionality was already accounted for ... The functionality is factored out into the Resources class here: If you are going to change the method contract you will need to update the Resource.delete() javadoc to explain what you are about, and remove the Resources.delete( Resource ) method as it will now be useless. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think that is a bad idea, because deleting recursively can happen a lot more efficiently in a JDBC database (with a lot less queries than would happen if you call the Resources.delete method) Note that there is also a store.remove() function which is recursive (and returns true if the resource didn't exist yet - which is also a contradiction). There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Your feedback is a bit late, we can take it to geotools-devel. The issue with this one is you combined a good fix (that needed to be back ported) with an API change which did not - so I had to split it up. |
||
|
||
@Override | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is tricky logic, would love to know the file was written out at lest once :) Thinking about a resource against a directory with no write access. The tmp file would be created, the move would fail, and each successive close would produce the same error ...
You can decide if you care.