W jaki sposób aplikacje Mac mogą śledzić lokalizację pliku?


18

Na moim komputerze Mac obserwuję takie zachowanie:

  • Otwórz plik PDF za pomocą PDF Expert, wprowadź zmiany w pliku, przenieś plik w Finderze, zapisz go w PDF Expert, a zostanie poprawnie zapisany w nowym miejscu.
  • Otwórz powłokę w katalogu, na przykład ~/foo, usuń katalog z inną aplikacją, a pwd powłoki poprawnie wyprowadza ~/.Trash/foo.

Co dzieje się pod maską? Przypadki te wydają się wskazywać, że aplikacje nie tylko utrzymują bezwzględną ścieżkę do pliku, jak emacs (czy mam rację?), Czy też jest to zupełnie inny mechanizm?

Odpowiedzi:


21

macos ma specjalny /.vol/system odwzorowany na rzeczywisty katalog i pliki. Pliki i katalogi są dostępne za pośrednictwem /.vol/<device_id>/<inode_number>, niezależnie od tego, gdzie znajdują się pliki w systemie plików.

To jest ładny mały system.

Programy mogą na przykład uzyskać numer /Users/jdoe/someFile.txti- węzła, a następnie otworzyć go za pomocą /.vol/12345/6789(w tym przypadku identyfikator urządzenia to 12345, a numer i-węzła 6789). Następnie przenosisz /Users/jdoe/someFile.txtgdziekolwiek chcesz (na tym samym wolumenie) i wszystko po prostu działa. Możesz nawet napisać skrypt powłoki, który to obsługuje magic.

ls -di <file> uzyskać numer i-węzła.

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

EDYTOWAĆ:

Użyć stat, aby uzyskać identyfikator numeru objętości i-węzła, według połączonej odpowiedzi jako wyróżnionego przez IMSoP.

GetFileInfo /.vol/12345/6789zwróci bieżącą lokalizację pliku wcześniej znajdującego się w /Users/jdoe/someFile.txt.

Aby uzyskać więcej informacji, zobacz /programming/11951328/is-there-any-function-to-retrieve-the-path-associated-with-an-inode


1
Zgodnie z połączonymi odpowiedziami statjest to bardziej przydatne polecenie ls -di, ponieważ podaje ono identyfikator woluminu / urządzenia, a także identyfikator pliku / numer i-węzła.
IMSoP,

4
W Debianie nie mam /.vol/i nadal tak się dzieje (chociaż potrzebuję pwd -P, tylko wtedy pwdaktualizacja zwykłego pliku jest aktualizowana). Wydaje mi się, że programy nie muszą otwierać plików specjalną ścieżką, ponieważ generalnie uzyskują (i zachowują) deskryptory plików, które i tak są mapowane na i-węzły przez jądro. Podejrzewam , że na komputerze Mac również /.vol/nie jest to konieczne.
Kamil Maciorowski

Jeśli więc przeniesiesz plik na inny dysk, ten schemat się zepsuje.
Joel Coehoorn

1
@JoelCoehoorn Tak, ale technicznie nie można przenieść pliku na inny dysk. Możesz skopiować go na inny dysk, a następnie usunąć, a istnieją skróty, aby to zrobić jako „jeden krok”, ale nadal jest to kopiowanie i usuwanie, a nie przenoszenie, więc technicznie inny plik.
ibrewster,

1
Wiele edytorów tekstu odczytuje dany plik, zamyka go, pracuje z jego kopią i zapisuje w tej samej ścieżce, aby odtworzyć plik w jego starej lokalizacji. Ale mogą cały czas pozostawać otwarte i zapisywać je na samym końcu. My bashna Debianie to robi. Uruchamiam exec 3<>foo, następnie przenoszę się foow tym samym systemie plików echo whatever >&3, a następnie sprawdzam foow nowej lokalizacji - i to się zmieniło. Chociaż bashnie można wyszukiwać w pliku, inne programy mogą to zrobić. Moja uwaga /.vol/nie jest niezbędna, bez tego programy mogą z łatwością działać w ten sposób. Albo nie rozumiem, jaka jest różnica.
Kamil Maciorowski

1

Odpowiedź poniżej jest fałszywa (patrz komentarze). Proszę ignorować


Oprócz dobrej odpowiedzi, którą udzielił thecarpy, jest prawdopodobne, że twoje programy po prostu trzymają uchwyt pliku , który jest niezależny od lokalizacji plików w drzewie katalogów (a w systemach Unix nawet utrzymuje usunięcie pliku, przynajmniej dopóki go nie zamkniesz. ).

Uchwyt pliku to w zasadzie bezpośredni dostęp do pliku, niezależnie od tego, gdzie i jak często (w przypadku linków twardych) istnieje on w strukturze katalogów.


Nie, też tego nie dostałeś, myślę ... zobacz mój komentarz do @KamilMaciorowski. Uchwyt pliku nie zmienia się, kiedy następnie zapisujesz plik, nowy plik jest tworzony w oryginalnej lokalizacji ... nie tak na macos!
thecarpy

1
Masz rację, to jest bardzo nieoczekiwane i bardzo odmienne od Uniksa. :(
Tom

Uzgodnione i pochwalone!
thecarpy

0

Chociaż nie jestem pewien, dlaczego macos używa tego zamiast standardowej funkcjonalności C, zakładając, że to, co przeczytałem lata temu w „Mac OS X Unleashed” jest prawidłowe, okazuje się, że znowu nauczyłem się czegoś nowego.

Proszę spojrzeć na następujący prosty program 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);
}

Skompiluj program, uruchom go w tle i szybko mv file.txt file2.txtZANIM program wydrukuje „Zakończony sen, zapis do pliku”. (masz 10 sekund)

Zauważ, że file2.txtma wyjście twojego programu, chociaż zostało ono przeniesione przed wydrukowaniem tekstu do pliku (poprzez deskryptor pliku).

$ 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

ZASTRZEŻENIE: Nie przyciąłem listy „uwzględnij”, ta została szybko zhakowana razem, aby udowodnić, że ma rację.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.