In che modo le app Mac sono in grado di tracciare la posizione di un file?


18

Osservo comportamenti come questo sul mio Mac:

  • Apri un PDF con PDF Expert, apporta alcune modifiche al file, sposta il file nel Finder, salvalo in PDF Expert e verrà salvato correttamente nella nuova posizione.
  • Apri una shell in una directory come ~/foo, svuota la directory con un'altra app e il pwd della shell viene visualizzato correttamente ~/.Trash/foo.

Cosa sta succedendo sotto il cofano? Questi casi sembrano indicare che le app non tengono solo un percorso assoluto del file come emacs (ho ragione con questo?) O è un meccanismo completamente diverso?

Risposte:


21

macos ha un /.vol/sistema speciale mappato alla directory e ai file effettivi. I file e le directory sono accessibili tramite/.vol/<device_id>/<inode_number> , indipendentemente da dove si trovano i file nel file system.

È un piccolo sistema carino.

Quindi, ad esempio, i programmi possono ottenere il numero di inode di /Users/jdoe/someFile.txte quindi aprirlo tramite /.vol/12345/6789(in questo caso, l'ID del dispositivo è 12345 e il numero di inode 6789). Quindi ti sposti /Users/jdoe/someFile.txtdove vuoi (sullo stesso volume) e tutto funziona. Puoi persino scrivere uno script di shell che supporti questo magic.

ls -di <file> per ottenere il numero di inode.

$ ls -di /User/jdoe/someFile.txt
6789 /User/jdoe/someFile.txt

MODIFICARE:

Si utilizza statper ottenere l'id del volume e il numero di inode, in base alla risposta collegata evidenziata da IMSoP.

GetFileInfo /.vol/12345/6789restituirebbe la posizione corrente del file precedentemente localizzato /Users/jdoe/someFile.txt.

Vedi /programming/11951328/is-there-any-function-to-retrieve-the-path-associated-with-an-inode per maggiori informazioni.


1
In base alle risposte collegate, qui statè un comando più utile di ls -di, poiché indica il volume / ID dispositivo, nonché l'ID file / numero di inode.
IMSoP

4
In Debian non ho /.vol/e questo succede ancora (anche se ho bisogno pwd -P, solo allora l'output di plain pwdviene aggiornato). Immagino che i programmi non debbano aprire i file tramite alcun percorso speciale perché in generale ottengono (e mantengono) descrittori di file che sono mappati agli inode dal kernel. Ho il sospetto che su Mac /.vol/non è essenziale pure.
Kamil Maciorowski l'

Quindi, se sposti un file su un altro disco, questo schema si interrompe.
Joel Coehoorn,

1
@JoelCoehoorn Sì, ma tecnicamente non puoi spostare un file su un altro disco. Puoi copiarlo sull'altro disco, quindi eliminarlo, e ci sono scorciatoie per farlo come "un passo", ma è ancora un copia-e-cancella, non uno spostamento, quindi tecnicamente un file diverso.
ibrewster,

1
Molti editor di testo leggono un determinato file, lo chiudono, lavorano con la sua copia e salvano nello stesso percorso, quindi ricreano il file nella sua posizione precedente. Ma potrebbero tenere il file sempre aperto e scriverlo alla fine. My bashon Debian lo fa. Corro exec 3<>foo, poi mi sono spostato fooall'interno dello stesso filesystem echo whatever >&3, quindi ho controllato foonella nuova posizione - ed è cambiato. Sebbene bashnon sia possibile cercare all'interno del file, altri programmi in generale possono farlo. Il mio punto /.vol/non è essenziale, i programmi possono facilmente funzionare così senza di essa. O non capisco qual è la differenza.
Kamil Maciorowski il

1

La risposta sotto è falsa (vedi commenti). Per favore, ignora


Oltre alla buona risposta fornita da Carpy, è probabile che i tuoi programmi stiano semplicemente trattenendo un handle di file , che è indipendente dalla posizione dei file nella struttura di directory (e sui sistemi Unix persiste persino nella cancellazione dei file, almeno fino a quando non lo chiudi ).

Un handle di file è sostanzialmente l'accesso diretto al file, indipendentemente da dove o con quale frequenza (nel caso di hardlink) esiste nella struttura della directory.


No, neanche tu l'hai capito, penso ... vedi il mio commento a @KamilMaciorowski. Il filehandle non cambia, quando si salva il file, viene creato un nuovo file nella posizione originale .... non così su macos!
thararpy

1
Hai ragione, è molto inaspettato e molto diverso da Unix. :(
Tom,

Concordato e votato!
giovedì,

0

Anche se non sono sicuro del motivo per cui macos utilizza questa funzionalità anziché la funzionalità C standard, supponendo che ciò che ho letto anni fa in "Mac OS X Unleashed" sia corretto, si scopre che ho imparato di nuovo qualcosa di nuovo.

Si prega di guardare il seguente semplice programma C:

#include <stdio.h>
#include <time.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdlib.h>

int main()
{
    struct timespec ts;
        ts.tv_sec = 10;
        ts.tv_nsec = 0;
    FILE * fp;

    fp = fopen("file.txt", "a");
    int f = fileno(fp);

    if (fp == NULL)
    {
        printf("Error opening file!\n");
        exit(1);
    }

    struct stat file_stat;
    int ret;
    ret = fstat (f, &file_stat);
    printf("inode number is %d\n", file_stat.st_ino);
    nanosleep(&ts, NULL);

    printf("Finished sleep, writing to file.\n");

/* print some text */
    const char *text = "Write this to the file";
    dprintf(f, "Some text: %s\n", text);

/* print integers and floats */
    int i = 1;
    float py = 3.1415927;
    dprintf(f, "Integer: %d, float: %f\n", i, py);

/* printing single characters */
    char c = 'A';
    dprintf(f, "A character: %c\n", c);

    close(f);
}

Compilare il programma, eseguirlo in background e rapidamente mv file.txt file2.txtPRIMA che il programma stampi "Sospensione terminata, scrittura su file". (hai 10 secondi)

Si noti che file2.txtha l'output del programma sebbene sia stato spostato prima che il testo fosse stampato nel file (tramite il descrittore di file).

$ gcc myfile.c
$ ./a.out &
[1] 21416
$ inode number is 83956
$ ./mv file.txt file2.txt
$ Finished sleep, writing to file.
[1]+  Done                    ./a.out
$ cat file2.txt
Some text: Write this to the file
Integer: 1, float: 3.141593
A character: A

DISCLAIMER: Non ho eliminato l'elenco "include", questo è stato rapidamente violato insieme per dimostrare un punto.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.