Ripristino cancellato di file Linux

Question

C'è un modo per creare un file in Linux che si colleghi a un iNode specifico? Prendi questo scenario: C'è un file in fase di scrittura (forse un log) e il file specifico è cancellato ma un link nel dir/proc lo sta ancora puntando. In questo caso abbiamo bisogno di non di una copia nuda ma di un hard link ad esso così possiamo avere le future modifiche e l'ultima modifica prima che il processo si chiuda e il sistema lo cancelli.

Se il numero di iNode è un modo per raggiungere questo obiettivo?

Answer 1

È possibile utilizzare lsof per recuperare file cancellati (a volte) ...

> lsof | grep testing.txt 
less 4607 juliet 4r REG 254,4 21 
     8880214 /home/juliet/testing.txt (deleted) 

Assicurarsi di leggere l'articolo originale per tutti i dettagli prima di tentare questo, a meno che non sei un Maveric come me.

> ls -l /proc/4607/fd/4 
lr-x------ 1 juliet juliet 64 Apr 7 03:19 
     /proc/4607/fd/4 -> /home/juliet/testing.txt (deleted) 
> cp /proc/4607/fd/4 testing.txt.bk 

http://www.linuxplanet.com/linuxplanet/tips/6767/1

Godetevi

Answer 2

E 'sempre difficile rispondere a una domanda del tipo "posso fare" con fiducia in senso negativo. Ma per quanto vedo, né/sys/né/proc forniscono una mappatura dei descrittori di file aperti che non sono collegamenti simbolici. Presumo da "MA un collegamento nel dir/proc lo sta ancora indicando" vuoi dire che/proc // fd/entries sembrano collegamenti simbolici? Sono quasi sicuro che non puoi recuperare il file originale.

Riprendo quello: come ha fatto notare l'utente26266075, la copia funziona. Solo hardlinking non ...

UPDATE: Se ci pensate, è abbastanza logico.

• /proc e/sys sono file system diversi dal disco rigido. Quindi non possono fornire file come voci di directory che potrebbero essere collegate a una destinazione sul disco rigido.

• Le voci/proc/*/fd/fingono di essere collegamenti simbolici, ma in realtà sono diverse, altrimenti la copia non funzionerebbe. Penso che fingano di essere collegamenti simbolici per fornire informazioni significative con 'ln -l'.

• Per quanto riguarda la capacità (mancante) per collegamento reale a un certo inode (diciamo con qualche chiamata di sistema): Questo non può essere parte del kernel o il VFS-Interface, per i seguenti motivi:

  • Sarebbe violare l'integrità del file system. Il filesystem non dovrebbe mantenere i blocchi del disco dei file che sono completamente cancellati nello stesso modo dei file che persistono.

  • Gli inodi potrebbero essere un concetto completamente virtuale per identificare uno "slot in cui è archiviato un flusso di dati". Suppongo che possano esserci implementazioni che avrebbero un problema nella conversione di uno slot che non ha alcun riferimento a uno slot a cui viene fatto riferimento a da un nome nel file system.

  ammetto il caso contro la possibilità di una tale chiamata di sistema non è a tenuta stagna. Ma allo stato attuale dell'interfaccia VFS (che AFAIR non prevede tale chiamata), sarebbe un pesante fardello per qualsiasi implementazione del file system (ad esfile system distribuiti) per fornire una chiamata per collegare un file in una directory tramite inode.

ATM Mi chiedo se chiamare fstat prima e dopo l'eliminazione l'ultimo riferimento è in realtà richiede di restituire le stesse informazioni inode ... t

Answer 3

Poiché non v'è Syscall che coinvolge iNode, perché è un concetto di extX fs e non è una buona pratica fare una stufa ma è fare una catena di responsabilità (come suggerisce MEL), c'è solo una risposta NO per questa domanda perché a livello VFS gestiamo il percorso e i nomi dei file e non altre rappresentazioni interne.

MA per raggiungere l'obiettivo di monitorare il più ultima modifica possiamo utilizzare un sistema di monitoraggio continuo e la duplicazione con coda:

tail -c+1 -f --pid=PID /proc/PID/fd/FD > /path/to/the/copy 

dove PID è il pid del processo che hanno il file eliminato ancora aperto e FD è il suo numero di descrittore di file. Con -f coda aperta e tenere premuto il file per visualizzare ulteriori modifiche, con -c + 1 iniziare a "coda" dal primo byte e con --pid = PID coda viene informato di uscire quando l'uscita pid .