Linux: come può essere creata una directory senza "." E ".."?

Non sono sicuro se il seguente problema è specifico per busybox: Ho un dispositivo incorporato con busybox installato. Da quanto ho capito, quando viene creata una directory, di solito verranno creati automaticamente 2 file nascosti: . per rappresentare la directory corrente e .. per rappresentare la directory principale. Ad esempio, digitando mkdir -p /tmp/normal_dir; cd /tmp/normal_dir; ls -a, l'output sarà . ...

Tuttavia, ho visto un caso in cui una directory esistente ( /tmp/strange_dir ) non mostra . e ... Cioè, digitando cd /tmp/strange_dir; ls -a, l'output è vuoto, sebbene la navigazione nella directory principale funzioni ancora. Cioè, digitando cd .., il contenuto è corretto.

La mia domanda è: come potrebbe una tale directory senza . e .. (piace /tmp/strange_dir ) essere creato? Sono confuso.

Questo può accadere se si accede alla directory tramite un link simbolico, ma la directory collegata viene rimossa. Ad esempio, in /tmp, creiamo una directory e un link simbolico a quella directory:

$ cd /tmp
$ mkdir normal_dir
$ ln -s normal_dir strange_dir

Ora, se navighiamo strange_dir, otteniamo l'output atteso:

$ cd strange_dir
$ ls -a
. ..

Se, tuttavia, rimuoviamo la directory normal_dir senza cambiando la directory, anzi otteniamo un risultato interessante:

$ rmdir /tmp/normal_dir
$ ls -a

$ ls -al
total 0

Quindi, anche se il nostro link ora non punta a nulla, la "directory" funzionante della shell è sempre la stessa:

$ pwd
/tmp/strange_dir

$ cd /tmp/strange_dir
bash: cd: /tmp/strange_dir: No such file or directory

$ ls -al
total 0

In esecuzione stat -L . mentre la nostra directory di lavoro è ancora a /tmp/strange_dir mostrerà ora Size: 0 come discusso nei commenti sopra. Sebbene l'output di ls non mostra niente ora (nemmeno . né .. ), noi può navigare ancora bene nella directory principale .. in questo caso, come hai sottolineato:

$ cd ..
$ pwd
/tmp

$ ls -a
. .. strange_dir

Sebbene il link simbolico esista ancora, non punta a nulla, quindi non possiamo cd di nuovo in strange_dir a questo punto, salvo che la directory /tmp/normal_dir viene ricreato. Per pulire, possiamo semplicemente rimuovere il link simbolico chiamando rm /tmp/strange_dir.

È concepibile che tale aberrazione possa essere creata se qualcuno ha detto

mkdir /tmp/strange_dir

in un momento in cui il filesystem era pieno (cioè non c'erano blocchi liberi). Sarebbe ancora (probabilmente) stato possibile creare il strange_dir voce di directory in /tmp, perché ciò richiederebbe solo pochi byte di spazio inutilizzato in uno dei blocchi già assegnati /tmp. Ma sarebbe stato impossibile assegnare un blocco per strange_dir si, e quindi sarebbe stato impossibile creare il . e .. inserimenti. In tal caso, Mi aspetterei che mkdir programma da rimuovere (scollegare) il strange_dir voce di directory in /tmp, ma il software non sempre fa ciò che mi aspetto.

Altre possibilità:

• mkdir ottenuto interrotto (terminato) tra la creazione del strange_dir voce di directory in /tmp e creando il . e .. voci in strange_dir. Mi aspetterei mkdir per catturare il segnale di interruzione (Cioè, Ctrl + C ) e ripulire se stesso, ma vedi sopra per quanto riguarda il software e le mie aspettative su di esso. E, naturalmente, non può catturare il segnale di uccisione o un crash del sistema.
• rmdir ottenuto interrotto (terminato) tra lo scollegamento del . e .. voci in strange_dir e scollegare il strange_dir voce di directory in /tmp.

Ci si potrebbe aspettare che il fsck che corre dopo un incidente rileverà il strange_dir e fare qualcosa al riguardo, ma ....

Sì, certo, se una directory ha una dimensione pari a 0, ciò significa che non ha nessun blocco ad esso assegnato, e quindi non può avere alcun contenuto (nemmeno quelli piccoli come . e .. ).

Non capisco del tutto perché cd .. funzionerebbe quando non c'è .., ma vedi la discussione in Rimozione di una directory dall'interno utilizzando l'interfaccia della riga di comando . Si scopre che

mkdir /tmp/strange_dir
cd /tmp/strange_dir
ls -lai                 ←  Mostra normale  .  e  .. , con numeri di inode.  rmdir / tmp / strange_dir
pwd ←  Ancora rapporti  / Tmp / strange_dir
ls -lai ←  Mostra la directory vuota:  Totale 0
ls -ldi ←  Spettacoli  .  con lo stesso numero di inode che aveva prima,
                          ma con una dimensione di 0 e un conteggio dei collegamenti pari a 0.  cd .. ←  Ti rimette in  / tmp 

Questa situazione non è perfettamente analoga a quella in questa domanda, perché, in questo altro caso, strange_dir viene rimosso da /tmp. Ma lo suggerisce cd .. è speciale, e talvolta funziona quando non esiste un meccanismo ovvio con il quale potrebbe farlo.

Strana differenza tra pwd e / bin / pwd suggerisce una possibilità su come questo potrebbe funzionare. La shell tiene traccia della tua directory attuale. Cioè, tiene traccia di una migliore ipotesi su quale sia la directory corrente. Può essere ingannato da link simbolici e trucchi come

mkdir /tmp/foo
cd /tmp/foo
mv /tmp/foo /tmp/foobar

vale a dire, penserà ancora che la directory corrente sia /tmp/foo, e così è quello pwd riferirà, ma pwd -P e /bin/pwd riferirà /tmp/foobar. Quindi, potrebbe essere quello, se chdir("..") non riesce, la shell calcola ciò che pensa debba essere la tua directory di livello superiore, e ci va assolutamente (Ma sospetto che ci sia dell'altro.)

Grazie per le discussioni finora. Di seguito è riportata una spiegazione da un mio collega che non è un membro della comunità Super User:

/tmp/strange_dir nel mio caso è una directory NBD / VFS (Network Block Device / Virtual File System). Questo tipo di file system virtuale si differenzia dai file system più tradizionali e ha una propria implementazione dei comandi della shell. Quindi non sorprende che, quando la directory è vuota, ls -a mostra niente ma cd .. consente di risalire alla sua directory principale.