Ordner kann nicht gelöscht werden

  • Huhu,


    folgendes ist passiert:


    Ich musste ein Downgrade von 551 zurück auf 516 machen weil mein NAS mit der neuen FW immer spontane Reboots hingelegt hat.

    Dabei wurde meine PhotosStation gekillt (konnte nicht mehr gestartet werden. App wurde anschließend ohne Fehlermeldung deinstalliert. Die Neuinstallation scheiterte aber. Dann habe ich mit WinSCP mal nachgeschaut und es war noch ein alter Ordner photostation2 vorhanden. Den habe ich in photostation2-alt umbenannt (siehe Bild). Anschließend konnte PhotoStation wieder installiert werden. Jetzt bekomme ich den Ordner photostaion2-alt nicht gelöscht obwohl er leer ist. Der Ordner befindet sich im Installationsordner der QPKGs.

  • Wie versuchst du zu löschen?

  • Ja, das interessiert mich auch. .qpkg/photostation war auch genau der Ordner, der sich bei mir nicht löschen ließ - weil eben das QTS-"EXT4"-Filesystem - allerdings vom 0537! - u.a. diese HTrees durcheinander gebracht hat. (Siehe hier)


    (mach mal ls -al, ob da Fragezeichen kommen ...)

  • frosch2
    Habe es erst mit WinSCP versucht und dann mit der Methode von UpSpin


    Sumpfdotter


    Wie oben erwähnt kam ich von 4.3.40551. Da machte mein NAS immer spontane Reboots ohne Grund.

    Deswegen ein Downgrade auf 4.3.40516. Nach dem Reboot wurde Photostation nicht sauber gestartet. Habe darauf gewartet bis im AppStore die Anzeige abbrechen kam. Habe dann Photostation gestoppt und das NAS neugestartet. Nachdem entschlüssel des Volumes, die App deinstalliert, was sauber durchlief. Danach konnte ich die App nicht mehr installieren. Bis dann den Ordner in photostation2 in ...-alt umbenannt habe. Komischerweise blieb der trotz deinstallation da.

    Ja es kommen Fragezeichen.

  • Wenn Du die Fragezeichen hast, dann kann ich Dir den oben zitierten Thread empfehlen. Die Verzeichnisse Deines ext4-Dateisystems sind so denke ich in einem inkonsistenten Zustand: Es gibt korrupte, sog. HTree-Indizes. Glücklicherweise sind diese Indizes redundant und man kann sie reparieren lassen. Allerdings hat das QTS-Interne e2fsck bei mir versagt. Anschließend hatte ich doppelte Dateieinträge, und die Indizes wurden immer wieder und wieder korrupt. Wie ich in dem Thread schon schrieb, vermute ich, dass es vielleicht garnicht am konkreten Build liegt, sondern dass der Fehler im System schlummern könnte, und er mit einem bestimmten Upgrade-Schritt zu Tage tritt ...


    Hier werde ich noch ein paar Sachen zu meiner QNAP-ext4-Analyse ergänzen: QNAP ext4-Kompatibel ja/nein?

  • Hm, Dann verschiebe ich mal meine ganzen Daten auf einen USB-Datenträger. Mal schauen ob es da mecker gibt. Ansonsten mach ich das NAS mal wieder , dank Qnap, platt.

  • Wenn Du ein Backup hast, dann greife nicht mit QNAP darauf zu. So hab ich mein Backup auch noch zerschossen.

  • Ich gehe mal davon aus, wenn ich die Dateien verschiebe vom NAS zum USB Laufwerk, und er nicht meckert das sie i.O sind. Bei 537 bekam ich immer die Meldung das die Datei nicht verschoben werden konnte bzw. auf dem NAS nicht gelöscht werden konnte.

  • Ich kann nur versuchen, mich zu wiederholen: Ich hatte nach dem Auftreten des Fehlers meine Daten von QTS auf ein USB-Backup-Laufwerk gesichert, und dann sogar verifiziert. Danach die primären Datenträger neu aufgesetzt. Beim Restore vom USB-Backup dann der Schock: Das Filesystem im Backup-Laufwerk hatte ebenfalls korrupte Dir-Indizes, und damit war auch das Backup erstmal beschädigt, und zwar dieses Mal auch in meinen Nutzdaten.


    Das muss nicht heißen, dass bei Dir das gleiche passiert. Immerhin hatte ich das 0537er Build und als Ziel-Dateisystem das QTS-ext4. Wenn Dein USB-Laufwerk ein anderes Datei-System hat, hast Du vielleicht bessere Karten. Oder Du hast bessere Karten, weil Du das 0515er zum Kopieren verwendest.

  • Habe nochmal 551 aufgespielt. Und siehe da, ich konnte den Ordner löschen.

    Sollte ich weiterhin reboots haben werde ich mal ein neu Init fahren.