/volume1/@tmp

[itari]

Ich hab da irgendwie ein Problem mit dem Verzeichnis /volume1/@tmp. Ich kann das nicht anlegen (per Shell, Fehlermeldung: es wäre bereits da), ich kann es nicht benutzen (egal mit welchem Programm, Fehlermeldung: es kann nicht ge'stat' werden).

Weiß jemand warum das so ist? Gibt es eine Anwendung, die damit spielt? Oder hält sich der Disk Station Manager das Teil frei? Ich habe mal alle Dienste ausgeschaltet; trotzdem gibts die gleichen Meldungen.

Es ist kein Problem auf der Systempartition eine @tmp anzulegen: mkdir /@tmp geht. Nur auf /volume1 ist es das Problem: mkdir /volume1/@tmp.

Ich schreib hier in das Forum, weil es IMHO kein Undergrund-Thema oder systemspezifisches Problem ist.

itari

 

[QTip]

hab grad bei mir etwas probiert

cd /volume
@tmp existiert
@tmp umbenannt nach @tmp2, fuinktioniert
mkdir @tmp, fuinktioniert

>ll
drwxr-xr-x   5 admin root  4096 Sep 21 15:35 @database
drwxr-xr-x   5 root  root  4096 Oct 13 21:52 @download
drwxr-xr-x  15 root  root  4096 Oct 16 23:27 @optware
drwxrwxrwx   2 root  root  4096 Jul 13 01:16 @spool
drwxr-xr-x   2 root  root  4096 Oct 17 17:28 @tmp
drwxrwxrwx   3 root  root  4096 Oct 16 17:05 @tmp2
drwxrwxrwx   2 root  root  4096 Sep 19 21:51 NetBackup
-rw-------   1 root  root 10240 Oct 17 15:17 aquota.group
-rw-------   1 root  root 10240 Oct 17 15:17 aquota.user
drwxrwxrwx  17 root  root  4096 Oct 13 22:29 download
drwxr-xr-x   3 root  root  4096 Oct  4 20:29 home
drwx------   2 root  root 16384 Feb 15  2004 lost+found
drwxrwxrwx   5 root  root  4096 Jun 22 16:00 media
drwxrwxrwx   3 root  root  4096 Sep  7 03:24 music
drwxrwxrwx   7 root  root  4096 Oct 16 00:45 photo
drwxrwxrwx  30 root  root  4096 Oct 16 23:30 public
drwxrwxrwx  10 root  root 12288 Oct  4 01:57 software
drwxrwxrwx   3 root  root  4096 Aug 31 16:17 svn
drwxrwxrwx   4 root  root  4096 Sep 26 22:23 tmp
drwxrwxrwx   2 root  root  4096 Oct  3 15:30 video
drwxrwxrwx 132 root  root 12288 Oct 16 21:20 web

@tmp wieder gelöscht, funktioniert
@tmp2 wieder umbenannt in @tmp, funktioniert

also bei mir ist es nicht gesperrt, gibt es unsichtbare Verzeichnisse in Linux?

 

[noreway]

Unsichtbare Verzeichnisse beginnen mit einem . (Punkt) und können mit

ll -a

angezeigt werden.

Verschieben/Erstellen des @tmp Orders bei mir auch kein Problem.

 

[itari]

Oh es war ganz schlimm mit meiner @tmp. Sie war weder mit ls -la sichtbar, noch konnte ich sie mit irgendeinem normalen Kommando benutzen.

Ich bin dann mit dem debugfs auf das Dateisystem gegangen und konnte dort über die inoden-Nummer den Eintrag löschen. Die @tmp war als Directory registriert, hatte aber keinen Datenblock-Eintrag und war somit unbrauchbar. Es gibt gelegentlich Einträge in einem Verzeichnis ohne Datenblöcke (Shared Memory zum Beispiel), aber die haben einen anderen Typ. Hier ist wohl mal irgendwann was schief gelaufen.

Naja ist nun behoben.

itari

 

[SkyWombat]

Sind die @bla Verzeichnisse nicht die Raid 1 Sicherungen auf der 2. Platte?

 

[itari]

nö. Das sind ganz einfache 'versteckte' Verzeichnisse. Hat mit Raid überhaupt nichts zu tun.

itari

 

[SkyWombat]

Und warum sind dann alle Verzeichnisse, die du so auf der DS hast nochmal als @blub vorhanden? Und versteckte *nix Verzeichnisse fangen normalerweise mit nem "." an. Ok, nicht dass ich mich jetzt mit Raid auskennen wuerde....

 

[itari]

Den Begriff "versteckte Dateien" gibt es auf Unix/Linux eigentlich nicht, nur eine Konvention, dass Dateien, die mit einem Punkt anfangen, mit dem ls usw. nicht angezeigt werden. Im Gegensatz dazu gibt es ja auf DOS/Windows ein Dateiattribut für "versteckte Dateien" (was im Grunde auch nichts wirklich versteckt). Fast unsichtbar sind nur Datenströme, die als Alternate Data Stream in Dateien einbettet sind

Verzeichnisse die ich als 'versteckt' benannt hatte, also die mit @ anfangen, sind vor dem Disk Station Manager versteckt, mehr wollte ich eigentlich damit nicht ausdrücken.

Dateien in Unix/Linux kann man auch richtig verstecken. Erläuterung: Man kann Dateien auch nur per Inode-Nummer verwenden, also ohne einen Directory-Eintrag. Umgekehrt können Direktory-Einträge auch ohne Inodes existieren. Solche Fälle werden zum Beispiel beim fsck angezeigt (sind normalerweise pathologisch), aber sie sind eben auch möglich. Daneben werden auch eine Reihe nicht auf der Platte existierende Dateiarten (Pipes, Shares Memory, Message Queues), die aber eine Datenstruktur im Memory benötigen, auf eine Inode gemapped. Das gibt es auch unter NTFS; da werden diese Strukturen sogar auf die Platte geschrieben; kann man sich mit einem Platteneditor genau ansehen.

Anmerkung zu Raid: Raid hinterlässt keine Dateien, die man sehen kann, wird auf Block-Ebene abgehandelt.

itari