2009-11-13 25 views

Odpowiedz

-1

Jak wskazano w File.delete()

można użyć securityManager że rzuca exeception dla Ciebie.

3

delecja może zakończyć się niepowodzeniem ze względu na jedną lub kilka przyczyn:

  1. Plik nie istnieje (użyj File#exists() przetestować).
  2. pliku jest zablokowana (ponieważ jest otwarty przez inną aplikację (lub własnego kodu!).
  3. Nie jesteś upoważniony (ale to byłby rzucony SecurityException, nie zwrócony fałszywy!).

Jeśli więc nie uda się usunąć, wykonaj File#exists(), aby sprawdzić, czy jest to spowodowane przez 1) lub 2).

Podsumowując:

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 pamiętać, że file.exists() może również rzucić SecurityException. –

+0

Nie dostaniesz SecurityException, jeśli usuwanie nie powiedzie się z powodu uprawnień systemu plików. – Thilo

+0

Dostaniesz SecurityException tylko jeśli JVM jest skonfigurowana restrykcyjnie, na przykład, jeśli jesteś apletem. "Normalna" aplikacja nie byłaby tutaj piaskownicą. – Thilo

20

Hmm, co mogłem zrobić:

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.exists(), isDirectory() i list() mogą wszystkie rzucić SecurityExcepions. –

+0

@ Bob: To zdarza się tylko w piaskownicy. Pierwotna metoda delete() najprawdopodobniej również rzuciłaby wyjątek SecurityException.Ale dla kompletności, przypuszczam, że powinien ją złapać (i zwrócić "piaskownicę: brak dostępu do systemu plików") – Thilo

+0

@Thilo dodał, ale tak, adresowałem zadane pytanie, nie każda inna możliwość, gdy angażowałem się w plik I/O. :) –

21

W Javie 6, istnieje niestety nie da się ustalić, dlaczego plik nie może zostać usunięty. W Java 7 można zamiast tego użyć java.nio.file.Path#delete(), co da szczegółową przyczynę niepowodzenia, jeśli plik lub katalog nie może zostać usunięty.

Należy zauważyć, że file.list() może zwracać wpisy dla katalogów, które można usunąć. Dokumentacja API do usunięcia mówi, że tylko puste katalogi mogą być usunięte, ale katalog jest uważany za pusty, jeśli zawarte pliki to np. Pliki metadanych specyficzne dla systemu operacyjnego.

+7

Ta metoda usuwania wydaje się nie istnieć w Java 7 API. [link] (http://download.oracle.com/javase/7/docs/api/java/nio/file/Path.html) Edycja: właśnie znalazłem, że jest teraz w klasie Files. [link] (http://download.oracle.com/javase/7/docs/api/java/nio/file/Files.html) – RishiD

+0

Czy wyświetla się, gdy _a file_ nie może zostać usunięty? Typ zwrotu jest nieważny! Jego dokumenty są niejasne. Zapytał tutaj: http://stackoverflow.com/questions/19935624/java-nio-file-files-deletepath-path-void-return-type –

6

Pamiętaj, że może to być Twoja aplikacja, która uniemożliwi usunięcie pliku!

Jeśli wcześniej napisałeś do pliku i nie zamknąłeś programu piszącego, sam zamykasz plik.

+2

Podczas testowania w systemie Windows 7 przy użyciu Java 6 miałem ten problem również z czytnikiem . Próbowałem usunąć plik przed zamknięciem czytnika i nie udało się. – Doppelganger

4

Java 7 java.nio.file.Files klasa może być również używany:

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); 
} 
Powiązane problemy