-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Silent commit failure due to ignore renameTo return value #70
Comments
Probably highly related that I can't
Maybe journal is not closed somewhere, or just a plain Windows bug? |
Strange. I don't have Windows to test on but your case seems valid for checking the return value. |
If the rename does fail, we're in an awkward place. We can't wait for the previous file to be closed (that could take forever) and we can't delete it either. We could mark the entry as being dead in the journal so that stale data isn't read, but that leaks disk. The Windows file system model pretty much breaks DiskLruCache completely. |
I think as this library was made for Android, and Android is a Linux distribution, and Linux is a Unix system, you can expect it to work properly on any Unix system, but, unfortunately, nothing is guaranteed to Windows. |
I totally agree with that, but at the same time I should be able to build this library from sources... without failing tests anywhere where I have Java + Android SDK. However ignoring a well documented error scenario is still a valid issue here. I never said I want to use it in a Windows app. |
Hi @TWiStErRob, could you test with the original version of DiskLruCache from Android Open Source Project in http://grepcode.com/file_/repository.grepcode.com/java/ext/com.google.android/android-apps/4.4.4_r1/com/example/android/bitmapfun/util/DiskLruCache.java/?v=source? Thanks in advance 😄 |
Hmm, I just realized how much @sjudd had modified the library, this invalidates my first code example in the issue. The missing checks are still missing though, and I can't With the above file you sent I did the following (I'm not sure this is what you wanted):
The output is very similar to what I've quoted above. as @swankjesse said:
Probably there's nothing much to do, except maybe adding the checks to have better error reporting if anything breaks randomly on Android/Unix (we can't expect |
Now,
commit
callscompleteEdit
which has a linedirty.renameTo(clean);
File.renameTo
has a return value which is discarded. This may fail silently due to a clumsy way of writing the file (as seen above) and think that the commit was commited. However later whengetDiskCache.get(key)
is called it sees that the file is missing for the wrong reason.The reason for
renameTo
failing is because there still a handle open for it in the process and the OS (Windows) may prevent the rename and returnfalse
. (side note: the strange thing is that in the past I've been able to rename running/and-locked .exe files without any problems from non-Java apps)The line was mentioned in #67 where if you check the return value the operation will be still atomic and should throw an
IOException
as you do in 4c31913 which is a fix for #32.Also there are other 3
File.delete
calls which are not checked, mostly related to backup files but still worth checking the code (and intentionally ignoring it with a comment maybe).This issue was discovered when trying to build: https://github.com/sjudd/glide/tree/3.0a
The text was updated successfully, but these errors were encountered: