2009-11-13 11 views

risposta

-1

Come sottolineato in File.delete()

si può utilizzare un SecurityManager che getta l'exeception per voi.

3

Una delezione può fallire a causa di uno o più motivi:

  1. Il file non esiste (utilizzare File#exists() per testare).
  2. file è bloccato (perché è aperto da un'altra applicazione (o il proprio codice!).
  3. Non sei autorizzato (ma che avrebbe gettato una SecurityException, non restituiti falso!).

Quindi, ogni volta che la cancellazione fallisce, fare un File#exists() per verificare se è causato da 1) o 2).

riassunte:

if (!file.delete()) { 
    String message = file.exists() ? "is in use by another app" : "does not exist"; 
    throw new IOException("Cannot delete file, because file " + message + "."); 
} 
+0

@BalusC, ricordate che File.Exists() possono anche lanciare una SecurityException. –

+0

Non si otterrà un SecurityException se l'eliminazione non riesce a causa delle autorizzazioni del file system. – Thilo

+0

Si otterrà SecurityException solo se la propria JVM è configurata in modo restrittivo, ad esempio se si è un'applet. Una "normale" applicazione non sarebbe sandboxed qui. – Thilo

20

Hmm, meglio che potessi fare:

public String getReasonForFileDeletionFailureInPlainEnglish(File file) { 
    try { 
     if (!file.exists()) 
      return "It doesn't exist in the first place."; 
     else if (file.isDirectory() && file.list().length > 0) 
      return "It's a directory and it's not empty."; 
     else 
      return "Somebody else has it open, we don't have write permissions, or somebody stole my disk."; 
    } catch (SecurityException e) { 
     return "We're sandboxed and don't have filesystem access."; 
    } 
} 
+0

@Cory, file.exist(), isDirectory() e list() possono generare SecurityExcepions. –

+0

@Bob: ciò accade solo in una sandbox. E l'eliminazione originale() molto probabilmente avrebbe anche generato un SecurityException.Ma per completezza, suppongo che dovrebbe prenderlo (e restituire "sandboxed: nessun accesso al file system") – Thilo

+0

@Thilo aggiunto, ma sì, stavo rispondendo alla domanda posta, non tutte le altre possibilità quando si effettuava l'I/O del file. :) –

21

In Java 6, non c'è purtroppo alcun modo per determinare il motivo per cui un file non può essere eliminato. Con Java 7, invece, è possibile utilizzare java.nio.file.Path#delete(), che fornisce una causa dettagliata dell'errore, se il file o la directory non possono essere eliminati.

Si noti che file.list() può restituire voci per le directory, che possono essere eliminate. La documentazione API per delete dice che solo le directory vuote possono essere cancellate, ma una directory è considerata vuota, se i file contenuti sono ad es. File di metadati specifici del sistema operativo.

+7

Questo metodo di eliminazione non sembra esistere nell'API Java 7. [collegamento] (http://download.oracle.com/javase/7/docs/api/java/nio/file/Path.html) Modifica: appena trovato è ora nella classe File. [link] (http://download.oracle.com/javase/7/docs/api/java/nio/file/Files.html) – RishiD

+0

Viene generato quando _a file_ non viene eliminato? Il tipo di reso è nullo! I suoi documenti non sono chiari. Chiesto qui: http://stackoverflow.com/questions/19935624/java-nio-file-files-deletepath-path-void-return-type –

6

Ricorda che può essere la tua applicazione che impedisce l'eliminazione di un file!

Se prima hai scritto il file e non hai chiuso lo scrittore, stai bloccando il file da solo.

+2

Durante il test su Windows 7 con Java 6 ho avuto questo problema anche con un lettore . Ho provato a cancellare il file prima di chiudere il lettore e non è riuscito. – Doppelganger

4

Java 7 java.nio.file.Files classe può essere utilizzata anche:

http://docs.oracle.com/javase/tutorial/essential/io/delete.html

try { 
    Files.delete(path); 
} catch (NoSuchFileException x) { 
    System.err.format("%s: no such" + " file or directory%n", path); 
} catch (DirectoryNotEmptyException x) { 
    System.err.format("%s not empty%n", path); 
} catch (IOException x) { 
    // File permission problems are caught here. 
    System.err.println(x); 
} 
Problemi correlati