échec d'ouverture: EBUSY (périphérique ou ressource occupé)

Question

J'ai une erreur étrange dans mon Application.

Dans mon application, il est possible de télécharger une zipFile, lire le contenu de ce qu'il est et aussi le supprimer. Sa n'a pas d'importance ce que c'est exactement.

Problème: Seulement sur la Xoom de Motorola (version 4.0.4) je peux télécharger le fichier, décompressez-le, je peux lire les données et je peux tout supprimer. Mais si j'essaie de le Télécharger de nouveau le fichier et alors qu'il décompressez le fichier et copiez les fichiers sur la Carte SD, il se bloque avec le message d'erreur EBUSY (Périphérique ou ressource occupé).

1. Pourquoi est-il le fait de travailler uniquement la première fois?
2. Ce que signifie cette erreur?
3. Pourquoi j'ai cette erreur uniquement sur la Xoom?

Je ne trouve pas de solution pour cela. Sur tous les autres appareils, il fonctionne très bien, pas d'erreurs ou de problèmes.

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

Il se bloque à la ligne 35 dans mon ZipHelper classe:

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

getInputStream(entrée) ... et je ne sais pas vraiment pourquoi?

Est-il une méthode pour attendre que l'appareil ou le recours, quand il est occupé? C'est arrivé à chaque fois que j'essaie de décompresser le fichier, l'application tente de 5 heure (Téléchargement -> Décompresser) et il plante à chaque fois.

EDIT: Nous avons découvert, ce n'est pas seulement la Xoom. Nous avons aussi l'erreur avec l'Asus transformer avec la version 4.0.4

Answer 1

J'ai la grande Réponse à la question!! Le Problème vient du Système Android ou / et le système FAT32. Je ne peux pas expliquer comment le système de l'erreur, il a quelque chose à voir avec la suppression de fichiers et le Système FAT32.

Mais la solution est très simple: Avant de supprimer un Répertoire ou d'un Fichier: le renommer!

Code pour renommer:

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

C'est ça, si vous renommez le dossier ou le fichier avant de le supprimer, il n'y a aucune chance pour que le système essayez d'ouvrir un fichier existant de nouveau ou d'ouvrir le fichier que vous souhaitez enregistrer à nouveau (ou quelque chose comme ça).

Answer 2

Ce problème peut être causé par

• deux ou plusieurs processus de référence au même fichier

• fichier a été supprimé,mais la référence à ne pas être tué

Toutefois,la suppression,une seule référence a été tué,ou un ou plusieurs processus de référence à ce fichier aussi

vous pouvez étape par étape:

avant de supprimer le fichier, vous devez

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

Le fichier que vous avez été ouvert,et le processus qui référence le fichier que vous avez ouvert. aussi,cette commande ,nous montrent l'id de processus

que,

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

Surprise vous attend, O(∩_∩)O

bonne chance!

Answer 3

Il semble s'agir d'un verrou de système de fichiers persistant. Je l'ai corrigé sans toucher mon code, je pense que c'était en débranchant mon câble USB et en le rebranchant.

Answer 4

J'obtenais exactement la même erreur, j'ai essayé de débrancher, de redémarrer eclipse, etc. mais rien ne fonctionnait. J'ai finalement dû redémarrer le téléphone et tout s'est remis en place;)

Merci de m'avoir mis sur la bonne voie !!

Answer 5

J'ai remarqué cette erreur Sony Xperia lorsque le fichier dans le répertoire ne sont pas fermées après la rédaction de certains contenus, et je suis en train d'essayer d'accès(modifier/supprimer) le répertoire.

Assurez-vous de fermer le fichier correctement. Assurez-vous qu'aucun accès à vos fichiers. Alors vous l'habitude de venir à travers ce message d'erreur.

Si vous n'êtes pas sûr que tout programme peut accéder à votre répertoire, assurez-vous de supprimer/fermer) tous les fichiers dans le répertoire avant de supprimer le répertoire.

adb reboot est une option pour fermer les fichiers ouverts. Mais ce n'est pas une bonne option pour le faire.