open failed: EBUSY (Device or resource busy)

Question

I have a strange error in my App.

In my app it is possible to download a zipFile, read the content as what it is and also delete it. Its doesn't matter what exactly it is.

Problem: Only on the Motorola Xoom (version 4.0.4) I can download the file, unzip it, I can read the data and I can delete everything. But if I try to Download the file again and while it unzip the file and copy the files to SD-Card it crashes with the error EBUSY (Device or resource busy).

1. Why is it working only the first time?
2. What means that error?
3. Why i get this error only on the Xoom?

I can't find any solution for that. On all other devices it works fine, no errors or problems.

LogCat:

07-18 12:27:46.774: E/PrepareMagTask(10057): IOException
07-18 12:27:46.774: E/PrepareMagTask(10057): java.io.FileNotFoundException: /mnt/sdcard/Android/data/com.xxxxxx.android/files/content/23760/emag.db: open failed: EBUSY (Device or resource busy)
07-18 12:27:46.774: E/PrepareMagTask(10057):    at libcore.io.IoBridge.open(IoBridge.java:406)
07-18 12:27:46.774: E/PrepareMagTask(10057):    at java.io.FileOutputStream.<init>(FileOutputStream.java:88)
07-18 12:27:46.774: E/PrepareMagTask(10057):    at java.io.FileOutputStream.<init>(FileOutputStream.java:73)
07-18 12:27:46.774: E/PrepareMagTask(10057):    at com.xxxxx.android.util.io.ZipHelper.uncompressEntry(ZipHelper.java:35)
07-18 12:27:46.774: E/PrepareMagTask(10057):    at com.xxxxx.android.task.PrepareMagTask.doInBackground(PrepareMagTask.java:271)
07-18 12:27:46.774: E/PrepareMagTask(10057):    at com.xxxxx.android.task.PrepareMagTask.doInBackground(PrepareMagTask.java:1)
07-18 12:27:46.774: E/PrepareMagTask(10057):    at android.os.AsyncTask$2.call(AsyncTask.java:264)
07-18 12:27:46.774: E/PrepareMagTask(10057):    at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:305)
07-18 12:27:46.774: E/PrepareMagTask(10057):    at java.util.concurrent.FutureTask.run(FutureTask.java:137)
07-18 12:27:46.774: E/PrepareMagTask(10057):    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1076)
07-18 12:27:46.774: E/PrepareMagTask(10057):    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:569)
07-18 12:27:46.774: E/PrepareMagTask(10057):    at java.lang.Thread.run(Thread.java:856)
07-18 12:27:46.774: E/PrepareMagTask(10057): Caused by: libcore.io.ErrnoException: open failed: EBUSY (Device or resource busy)
07-18 12:27:46.774: E/PrepareMagTask(10057):    at libcore.io.Posix.open(Native Method)
07-18 12:27:46.774: E/PrepareMagTask(10057):    at libcore.io.BlockGuardOs.open(BlockGuardOs.java:110)
07-18 12:27:46.774: E/PrepareMagTask(10057):    at libcore.io.IoBridge.open(IoBridge.java:390)
07-18 12:27:46.774: E/PrepareMagTask(10057):    ... 11 more

It crashes at line 35 in my ZipHelper class:

FileHelper.copy(zipFile.getInputStream(entry), new FileOutputStream(outputFile), modify);

getInputStream(entry) ... and I really dont know why?

Is there a method to wait for the device or recourse, when it is busy? This is happened every time I try to unzip the file, the app tries it 5 time (Downloading -> Unzip) and it crashes every time.

EDIT: We found out, its not only the Xoom. We also have the error with the Asus Transformer with the version 4.0.4

Catenate

I have same problem. "root explorer" app was open. – Burnette

Answer 1

I have a big Answer!! The Problem comes from the Android System or/and the FAT32 system. I can not explain how the system gets the error, it has something to do with deleting files and the FAT32 System.

But the solution is really easy: Before you delete a Directory or File: rename it!

Code to rename:

final File to = new File(file.getAbsolutePath() + System.currentTimeMillis());
file.renameTo(to);
to.delete();

That's it, if you rename the folder or file before you delete it, there is no chance for the system to try to open an existing file again or an open file which you want to save again (or something like this).

Catenate

Any reason to use getAbsolutePath() instead of getPath()? – Newcomen

There is no reason, just to use the full path of this file, i think its also possible to use getPath(). No warranty :) – Catenate

@Mirko any ideas of a workaround when something gets deleted through another app? (ie. users that are deleting files from their system through a file manager app) – Mcneill

this solution is just to delete known files (of the app). If someone deletes files with a different app you cant do anything, just save files in the private disc space of your app – Catenate

Any other solution? Or the reason cause this? I would like to save something on public storage e.g. /sdcard/ . If the user manually delete it, the problem come. – Dinitrobenzene

Combined with the answer from caopeng below, I've messed around with this and it looks like the sdcard process, owned by user media_rw, has a link to a deleted file which is locking everything up. Anyone have any better idea why this would happen than bad reboots / unexpected power loss in the middle of writing? Rename-before-delete sounds like a hack :( – Eisenhart

renaming is a workarround. the system keeps a reference to the deleted file some times, for some reason. Renaming just moves this reference to an "not-again-reachable"-file. In my case I deleted a zip and tried to download it again, which ended up really often in this error. Because the deleted file was the same, at the same path, as the one I downloaded again. – Catenate

If the file was deleted by another process, this does not work. – Attribution

Thank you so much! I've spent hours of debugging this issue! :) – Electrometer

Answer 2

This issue may be cause by

• two or more process reference the same file

• file was deleted,but the reference not be killed

However,deleted it,only one reference was killed,or one or more process reference this file also

you can step by step:

before you delete the file you should

• adb shell lsof | grep "com.xxxxxx.android"

The file you have been opened,and which process reference the file which you opened. also,this command ,show us the process id

than,

• adb shell ls -al /proc/%d/fd

Surprise waiting for you, O(∩_∩)O

good luck!

Agace

Answer 3

It seems to be a lingering filesystem lock. I fixed it without touching my code, I think it was by unplugging my USB cable and re-plugging it in.

Jimenez

I never had the error again after the "rename it befor delete it" rule. so i can't test your solution and i am also not sure if the device was always plugged in with USB. – Catenate

helped me, there was a lock, got solved by re-plugging, thanks – Puparium

Answer 4

Was getting the exact same error, tried unplugging, restarting eclipse etc but nothing was working. Finally had to reboot phone and all fell back into place ;)

Thanks for putting me on the right route !!

Aziza

Answer 5

I noticed this error in Sony Xperia when file in the directory not closed after writing some content in to it and I am trying to access(modify/delete) the directory.

Make sure to close the file properly. Make sure no program is accessing your files. Then you wont come across this error.

If you are unsure that any program might be accessing your directory, be sure to delete(/close) all the files in the directory before deleting the directory.

adb reboot is one option to close opened files. But that is not a good option to do so.

Motion

Answer 6

I understand that this is an old issue, and was originally reported specific to a XOOM, but if the OP had an open FileOutputStream that was not properly closed, i.e. via a Finally block, then that is likely what is causing the resource to be held when attempting to reference it later... even if the physical file was actually deleted.

Befriend

Answer 7

The message rm: could not remove directory (code EBUSY), means that some app or process is using the directory.

For me, this usually means AndroidStudio, Webstorm, or another IDE is open. If you have an IDE open, closing it can free up the process to remove the folder. After closing, just run the removal again.

Metagenesis

Answer 8

Adding one related findings, during some tests on lowend Android(mostly of some legacy hardwares that run Android 5.1) devices recently. For newer and faster devices, this rarely happens.

If you are trying to load files that are bundled in "assets" folder after a fresh installation, you may probably encounter this exception. The older and the slower the device is, the more chance you may meet it.

My guess is like this.

Asset resource files are compressed and stored in the APK file. When using asset manager to read it, the IO system needs to access this APK file, which is probably also processed by some other system component(installer? cache generator?) after a clean installation. When this is happening, it will raise the java.io.FileNotFoundException: ... open faield, EBUSY (Device or resource busy) exception.

My work-around to this failure is just waiting and retrying, though it may take a while. Meanwhile, I will give user a friendly notice of it.

Hope it helps.

Gemoets