2012-07-18 20 views
34

Tengo un error extraño en mi aplicación.error de apertura: EBUSY (dispositivo o recurso ocupado)

En mi aplicación, es posible descargar un archivo zip, leer el contenido tal como es y también eliminarlo. No importa qué es exactamente.

Problema: solo en el Motorola Xoom (versión 4.0.4) puedo descargar el archivo, descomprimirlo, puedo leer los datos y puedo borrar todo. Pero si trato de descargar el archivo nuevamente y mientras descomprime el archivo y copia los archivos a la tarjeta SD, se bloquea con el error EBUSY (dispositivo o recurso ocupado).

  1. ¿Por qué funciona solo la primera vez?
  2. ¿Qué significa ese error?
  3. ¿Por qué me sale este error solo en el Xoom?

No encontré ninguna solución para eso. En todos los demás dispositivos funciona bien, sin errores ni problemas.

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 

Se estrella en la línea 35 en mi clase ZipHelper:

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

getInputStream (entrada) ... y realmente no sé por qué?

¿Hay algún método para esperar al dispositivo o recurso cuando está ocupado? Esto ocurre cada vez que intento descomprimir el archivo, la aplicación lo intenta 5 veces (Descargando -> Descomprimir) y se cuelga todo el tiempo.

EDIT: descubrimos que no es solo el Xoom. También tenemos el error con el transformador de Asus con la versión 4.0.4

+1

Tengo el mismo problema. La aplicación "root explorer" estaba abierta. –

Respuesta

77

¡Tengo la gran respuesta! El problema proviene del sistema Android y/o del sistema FAT32. No puedo explicar cómo el sistema obtiene el error, tiene algo que ver con la eliminación de archivos y el sistema FAT32.

Pero la solución es realmente fácil: Antes de eliminar un directorio o archivo: ¡cámbiele el nombre!

Código para cambiar el nombre:

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

Eso es todo, si cambia el nombre de la carpeta o el archivo antes de eliminarlo, no hay ninguna posibilidad de que el sistema intente abrir un archivo existente de nuevo o un wich archivo abierto quieres guardar de nuevo (o algo como esto).

+1

¿Alguna razón para usar getAbsolutePath() en lugar de getPath()? –

+0

No hay ninguna razón, solo para usar la ruta completa de este archivo, creo que también es posible usar getPath(). Sin garantía :) – Informatic0re

+0

@Mirko ¿Tiene alguna idea de solución cuando algo se elimina a través de otra aplicación? (es decir, usuarios que están eliminando archivos de su sistema a través de una aplicación de administración de archivos) –

2

Parece que el bloqueo del sistema de archivos persiste. Lo arreglé sin tocar mi código, creo que fue desenchufando mi cable USB y volviéndolo a enchufar.

+0

No volví a tener el error después de la regla "cambiar el nombre antes de eliminarlo" . así que no puedo probar su solución y tampoco estoy seguro de si el dispositivo siempre fue enchufado con USB. – Informatic0re

+0

No. No funcionó para mí – drulabs

+0

me ayudó, hubo un bloqueo, se resolvió volviendo a enchufar, gracias – keybee

2

Estaba recibiendo exactamente el mismo error, intenté desconectarme, reiniciando eclipse, etc. pero nada funcionaba. Finalmente tuve que reiniciar el teléfono y todos cayeron en su lugar;)

Gracias por ponerme en la ruta correcta !!

0

me di cuenta de este error en el Sony Xperia cuando el archivo en el directorio no está cerrada después de escribir algunos contenidos a ella y yo estoy tratando de acceso (modificar/borrar) el directorio.

Asegúrese de cerrar correctamente el archivo. Asegúrese de que ningún programa acceda a sus archivos. Entonces no encontrarás este error.

Si no está seguro de que cualquier programa podría estar accediendo a su directorio, asegúrese de borrar (/ cerrar) todos los archivos en el directorio antes de eliminar el directorio.

reinicio adb es una opción para cerrar los archivos abiertos. Pero esa no es una buena opción para hacerlo.

6

Este problema puede ser causado por

  • dos o más procesos referencia al mismo archivo se ha eliminado

  • archivo, pero la referencia no ser matado

Sin embargo, lo eliminó, solo se eliminó una referencia, o uno o más referencia de proceso de este archivo también

puede paso a paso:

antes de eliminar el archivo que debe

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

El archivo que se han abierto y qué proceso hace referencia al archivo que abrió. También, este comando, nos muestran el identificador de proceso

que,

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

sorpresa esperando por ti, O (∩_∩) O

buena suerte!

0

Entiendo que este es un problema antiguo, y que originalmente se informó que era específico de una XOOM, pero si el OP tenía un FileOutputStream abierto que no se cerró correctamente, es decir, a través de un bloque Finally, es probable que sea el causante del recurso que debe retenerse cuando intenta hacer referencia más adelante ... incluso si el archivo físico fue realmente eliminado.

0

rm: could not remove directory (code EBUSY) El mensaje, significa que alguna aplicación o proceso está utilizando el directorio.

Para mí, esto generalmente significa Android Studio, WebStorm, u otro IDE está abierto. Si tiene un IDE abierto, cerrarlo puede liberar el proceso para eliminar la carpeta. Después del cierre, simplemente ejecuta la eliminación nuevamente.

Cuestiones relacionadas