Rechte und Zugriff auf das Dateisystem

1. Zugriffsrechte im Betriebssystem

Wenn Sie mit Dateien und Ordnern arbeiten, beachten Sie: Das Betriebssystem (OS) schützt sie mit einem System von Zugriffsrechten. Das bedeutet, dass nicht jedes Programm (und nicht jeder Benutzer) jede Datei lesen, ändern oder löschen darf.

POSIX (Linux, macOS u. a.)

In POSIX-Systemen (Unix, Linux, macOS) hat jede Datei und jeder Ordner Zugriffsrechte für drei Kategorien:

• Besitzer (user)
• Gruppe (group)
• Andere (others)

Für jede Kategorie gibt es drei Arten von Rechten:

• r – read (Lesen)
• w – write (Schreiben)
• x – execute (Ausführen)

Beispiel:
-rw-r--r--
Das bedeutet: Der Besitzer darf lesen und schreiben, die anderen nur lesen.

Windows

Unter Windows werden Zugriffsrechte über das ACL-System (Access Control List) festgelegt – Listen von Berechtigungen für Benutzer und Gruppen. Hier lässt sich flexibel konfigurieren, wer was mit einer Datei oder einem Ordner tun darf (lesen, schreiben, ändern, ausführen usw.).

Wichtig:
Ein Java-Programm arbeitet mit Dateien im Rahmen der Rechte des Benutzers, unter dem es gestartet wurde. Wenn der Benutzer keine Rechte auf die Datei hat, kann das Programm sie ebenfalls nicht lesen oder ändern.

2. Ausnahme AccessDeniedException und ihre Ursachen

Wenn Sie in Java mit Dateien arbeiten (insbesondere über das NIO-API), können Sie auf die Ausnahme stoßen:

java.nio.file.AccessDeniedException

Diese Ausnahme wird ausgelöst, wenn Ihr Programm keine Rechte hat, um eine Operation mit einer Datei oder einem Verzeichnis auszuführen.

Hauptursachen:

• Keine Rechte zum Lesen der Datei (z. B. ist die Datei gegen Lesen geschützt).
• Keine Rechte zum Schreiben in die Datei oder den Ordner (z. B. wird versucht, in einen Systemordner zu schreiben).
• Keine Rechte zum Ausführen der Datei (relevant für das Starten von Programmen).
• Ordner oder Datei sind vor Änderungen geschützt (z. B. schreibgeschützt).
• Datei oder Ordner werden von einem anderen Prozess verwendet (unter Windows besonders häufig).

Beispiel:

Path path = Paths.get("/etc/shadow"); // Systemdatei unter Linux
Files.readAllLines(path); // AccessDeniedException!

Was tun?

• Prüfen Sie die Zugriffsrechte für Datei/Ordner.
• Starten Sie das Programm unter einem Benutzer mit den erforderlichen Rechten.
• Versuchen Sie nicht, ohne Not in Systemverzeichnisse zu schreiben.

3. Prüfen der Rechte in Java: Methoden Files.isReadable(), isWritable(), isExecutable()

Java stellt bequeme Methoden bereit, um die Rechte auf eine Datei oder einen Ordner zu prüfen:

Path path = Paths.get("example.txt");

System.out.println(Files.isReadable(path));   // true, wenn Lesen erlaubt ist
System.out.println(Files.isWritable(path));   // true, wenn Schreiben erlaubt ist
System.out.println(Files.isExecutable(path)); // true, wenn Ausführen erlaubt ist

Diese Methoden zeigen, wie das System Ihre aktuellen Rechte sieht.

Aber!
Sie garantieren nicht, dass die Operation wirklich erfolgreich ist. Gründe können vielfältig sein: Die Datei kann von einem anderen Programm gesperrt sein, Rechte können sich nach der Prüfung geändert haben, auf Netzlaufwerken hängen die Ergebnisse vom Server ab, und manchmal meldet das Betriebssystem das eine, setzt aber andere Einschränkungen durch.

Daher ist es in Java besser, zuerst die Rechte zu prüfen und anschließend die eigentliche Lese- oder Schreiboperation in try-catch zu kapseln – das ist zuverlässiger.

TOCTOU-Problem (Time Of Check To Time Of Use)

Damit ist direkt die TOCTOU-Situation verbunden, bei der sich zwischen der Prüfung der Rechte und der eigentlichen Operation etwas ändert. Zum Beispiel:

1. Sie haben geprüft, dass die Datei zum Schreiben verfügbar ist (isWritable).
2. In diesem Moment ändert ein anderer Prozess oder Benutzer die Rechte – die Datei ist nun geschützt.
3. Sie versuchen zu schreiben – Sie erhalten AccessDeniedException.

Fazit:
Die Rechteprüfung liefert nur einen Hinweis auf den aktuellen Zustand, garantiert aber keine erfolgreiche Operation. Behandeln Sie beim Arbeiten mit Dateien immer Ausnahmen.

4. Prinzip des „sicheren Schreibens“ (atomic write)

Warum ist ein sicherer (atomarer) Schreibvorgang nötig?

Beim Schreiben einer Datei kann es zu einem Fehler kommen: Das Programm stürzt ab, der Strom fällt aus, es ist nicht genug Speicherplatz vorhanden... Infolgedessen kann die Datei beschädigt oder nur teilweise geschrieben sein. Das ist besonders gefährlich für wichtige Daten (z. B. Konfigurationen, Datenbanken, Dokumente).

Sicheres Schreiben ist eine Methode, die garantiert, dass die Datei entweder vollständig aktualisiert wird oder im alten Zustand verbleibt. Dieser Ansatz wird atomares Schreiben (atomic write) genannt.

Wie implementiert man sicheres Schreiben in Java?

Muster:

• Schreiben Sie die Daten in eine temporäre Datei (in der Regel im selben Ordner).
• War das Schreiben erfolgreich – verschieben Sie die temporäre Datei atomar an die Stelle der Zieldatei (ersetzen Sie diese).

Warum funktioniert das?
Das Verschieben einer Datei (rename/move) innerhalb desselben Dateisystems ist in der Regel atomar: Entweder wird die Datei vollständig ersetzt oder gar nicht. Wenn etwas schiefgeht, bleibt die Originaldatei unangetastet.

Codebeispiel: sicheres Schreiben einer Datei

import java.nio.file.*;

public class SafeWriteDemo {
    public static void safeWrite(Path target, byte[] data) throws Exception {
        // 1. Temporäre Datei im selben Ordner erstellen
        Path tempFile = Files.createTempFile(target.getParent(), "tmp_", ".tmp");

        try {
            // 2. Daten in die temporäre Datei schreiben
            Files.write(tempFile, data);

            // 3. Temporäre Datei atomar an den Zielort verschieben
            Files.move(
                tempFile,
                target,
                StandardCopyOption.REPLACE_EXISTING,
                StandardCopyOption.ATOMIC_MOVE
            );
        } finally {
            // Falls etwas schiefgeht – temporäre Datei löschen
            Files.deleteIfExists(tempFile);
        }
    }

    public static void main(String[] args) throws Exception {
        Path file = Paths.get("important.txt");
        byte[] content = "Sehr wichtige Daten".getBytes();

        safeWrite(file, content);
        System.out.println("Datei sicher geschrieben!");
    }
}

Beachten Sie:

• Wir verwenden Files.createTempFile() zum Erstellen der temporären Datei.
• Für das Verschieben nutzen wir die Option ATOMIC_MOVE – das garantiert Atomarität (sofern vom Betriebssystem und Dateisystem unterstützt).
• Geht etwas schief, wird die temporäre Datei gelöscht (Files.deleteIfExists).

Wann ist das besonders wichtig?

• Bei der Arbeit mit Konfigurationsdateien, Datenbanken, Logdateien.
• Wenn die Datei jederzeit von einem anderen Prozess gelesen werden kann.
• Wenn ein Fehler beim Schreiben zu Datenverlust oder -beschädigung führen kann.

5. Protokollierung und Behandlung von Zugriffsfehlern

Wie behandelt man Zugriffsfehler richtig?

Verwenden Sie bei der Arbeit mit Dateien immer eine Ausnahmebehandlung (try-catch). Das ermöglicht:

• Dem Benutzer die Problematik korrekt mitzuteilen (z. B. „Keine Schreibrechte für den Ordner“).
• Den Fehler zur späteren Analyse ins Log zu schreiben.
• Das Programm nicht wegen einer einzigen fehlgeschlagenen Operation „abzustürzen“.

Beispiel: Umgang mit AccessDeniedException

import java.nio.file.*;

public class FileAccessDemo {
    public static void main(String[] args) {
        Path file = Paths.get("/etc/shadow"); // Beispiel für Linux

        try {
            Files.readAllLines(file);
        } catch (AccessDeniedException ade) {
            System.err.println("Zugriffsfehler: keine Leserechte für die Datei " + file);
            // Kann in das Log geschrieben oder dem Benutzer eine alternative Datei angeboten werden
        } catch (Exception e) {
            System.err.println("Anderer Fehler: " + e.getMessage());
        }
    }
}

Fehlerprotokollierung

In realen Anwendungen verwenden Sie Protokollierungssysteme (z. B. java.util.logging, Log4j, SLF4J). Das ermöglicht:

• Fehler mit Details zu protokollieren (Stacktraces, Zeit, Benutzer).
• Logs zu analysieren, um Probleme zu finden und zu beheben.
• Dem Benutzer keine „erschreckenden“ Meldungen anzuzeigen, sondern sie nur ins Log zu schreiben.

Beispiel mit Protokollierung:

import java.nio.file.*;
import java.util.logging.*;

public class FileLoggerDemo {
    private static final Logger logger = Logger.getLogger(FileLoggerDemo.class.getName());

    public static void main(String[] args) {
        Path file = Paths.get("data.txt");

        try {
            Files.readAllLines(file);
        } catch (AccessDeniedException ade) {
            logger.severe("Kein Zugriff auf Datei: " + file);
        } catch (Exception e) {
            logger.log(Level.SEVERE, "Fehler bei der Dateiverarbeitung", e);
        }
    }
}

6. Typische Fehler

Fehler Nr. 1: Ausnahmen bei Dateizugriffen ignorieren.
Schreiben Sie niemals einfach Files.write(path, data) ohne try-catch – wenn etwas schiefgeht, stürzt das Programm ab.

Fehler Nr. 2: Rechteprüfung ohne Berücksichtigung von TOCTOU.
Verlassen Sie sich nicht nur auf Files.isWritable() und ähnliche Methoden. Selbst wenn sie „erlaubt“ zurückgeben, kann die Operation fehlschlagen. Behandeln Sie immer Ausnahmen (z. B. AccessDeniedException).

Fehler Nr. 3: Über eine bestehende Datei schreiben ohne Backup.
Wenn die Datei wichtig ist, erstellen Sie vor dem Schreiben ein Backup oder verwenden Sie atomares Schreiben mit StandardCopyOption.ATOMIC_MOVE.

Fehler Nr. 4: Temporäre Dateien nach einem Fehler nicht löschen.
Wenn beim atomaren Schreiben etwas schiefgeht, kann die temporäre Datei liegen bleiben. Verwenden Sie finally und Files.deleteIfExists().

Fehler Nr. 5: Zugriffsfehler nicht protokollieren.
Wenn das Programm eine Datei nicht schreiben oder lesen konnte, sollte der Benutzer darüber informiert werden, und Sie sollten Details im Log sehen. Verwenden Sie java.util.logging/SLF4J und protokollieren Sie Ausnahmen mit Stacktrace.