Ich gebe zu, der Titel ist nicht besonders aussagekräftig, aber mir fällt nichts besseres ein.

Ich bin im moment auf unserem CAD-Fileserver in einem Ordern mit Cadds Daten (irgend so ein CAD Tool, nicht so wichtig).

Hir sind 3 Ordner die sich sehr merkwürdig verhalten. Der eine hält sich für eine Datei von 1902, und die anderen beiden sind von der 2007 und 2037.

Außerdem zeigen sich bei einem ls -la rechtmerkwürdige Dinge:

?rwsrws--T 65534 <vielebyte> <vielebyte> <nochmehrbyte> Oct 9 1902 <name>

Daher dachte ich mir, lösch ich die drei einfach und zieh sie aus dem Backup neu rüber (wäre kein Thema, das letzte mal bearbeitet sind sie vor ein paar Monaten)...aber denkste! Sie lassen sich auch als root mit einem rm -rf nicht löschen, lassen sich nicht verschieben und mit dem Backup überschreiben geht auch nicht, da er dann meint er könnte Dateien nicht mit Ordnern überschreiben.

Leider werden die Daten recht dringend gebraucht und der verantwortliche für den Server ist zur Zeit leider nicht zu erreichen (sitzt im Zug nach irgendwo) und mir gehen die Ideen aus. Der Server ist neulich mal wegen eines fehlerhaften SCSI-Controllers gecrashed und hat beim hochfahren ziemlich lange mit fsck rumgemacht, möglicherweise stammend die Daten daher.

Möglicherweise könnte ein weiteres fsck das ganze wiever beheben, nur leider arbeiten im moment circa 30 Leute auf der Kiste und ich kann ihn nicht einfach mal für 2h vom Netz nehmen (und bei einem 1,5TB großen Raidarray braucht fsck recht lange).

Ideen anyone?

(Wenn nicht leg ich der Spätschicht nen Zettel hin und die machen das heut spät abends ^^)

Martin hat ein Brett vorm Kopf :autsch:

Die Lösung (okay keine Lösung, aber eine umgehung) ist so simpel das es fast weh tut:

Wir benennen einfach das Überverzeichnis in <name>_alt um, und kopieren dann das aus dem Backup rüber.

Aua ^^

Auch wenn die Antwort etwas spät kommt.

das T bedeutet, das ein Temporary bit gesetzt wurde.

(oder wie man das schreibt)

Dann darf slebst root das ding nichtmehr löschen.

Aber root kann natürlich das T-bit wieder entfernen.

chmod ugo-t ...

sollte es auf alle fälle tun