Zastanawiałem się, jak system Windows obsługuje dowiązania symboliczne. Domyślam się, że ich nie rozpozna, ale nie jestem do końca pewien.
Co też robią komputery Mac, gdy są konfrontowane?
Zastanawiałem się, jak system Windows obsługuje dowiązania symboliczne. Domyślam się, że ich nie rozpozna, ale nie jestem do końca pewien.
Co też robią komputery Mac, gdy są konfrontowane?
Odpowiedzi:
Zależy od wersji systemu Windows i konfiguracji po stronie serwera, gdy mówimy o dyskach nielokalnych.
Od Windows Vista system Windows ma ideę dowiązań symbolicznych, ale semantyka jest inna. Ale ważniejszym problemem tutaj powinny być nazwy ścieżek, które mają inną składnię. Na początek: jedno-zrootowane drzewo katalogów po stronie unixoidu i kilka liter dysku jako root po stronie Windows.
Po stronie unixoidu dowiązania symboliczne to tylko pliki tekstowe ze specjalną flagą. Po stronie systemu Windows podstawowy mechanizm nazywany jest punktem ponownej analizy. Mówi to menedżerowi obiektu, aby przekazał go do konkretnych zarejestrowanych filtrów (meta-data dla tego jest przechowywana w punktach ponownej analizy). W systemie Windows 2000 wprowadzono już jeden typ punktów ponownej analizy zwanych punktami połączenia (w przybliżeniu, ale nie całkiem, dowiązania symboliczne katalogu). W systemie Vista wprowadzono dowiązania symboliczne do plików i katalogów, także na dyskach zdalnych. W pewnym stopniu obsługiwane są również dowiązania symboliczne na dyskach zdalnych.
Chodzi przede wszystkim o to, czy sterownik systemu plików - gdy jest uruchamiany lokalnie - wprowadzałby zmiany w ścieżkach, które Windows widzi. W takim przypadku działałoby to w przypadku niektórych lokalnych / względnych dowiązań symbolicznych. W przypadku ścieżek bezwzględnych jako celów trudno będzie wydedukować, co to znaczy. To samo dotyczy zdalnych łączy dowiązań symbolicznych (do „udziałów sieciowych”).
Jeśli chodzi o stronę Mac, nie mam pojęcia i może to mieć sens jako osobne pytanie. Ale dopóki strona serwera przekazuje informację, że jest to dowiązanie symboliczne, nie widzę problemów, ponieważ oba postępują zgodnie z semantyką SUS (w przeciwieństwie do systemu Windows).
Rozważ punkty montowania bocznego systemu Linux:
/dev/sda1 /
/dev/sda2 /home
/dev/sda3 /var
A teraz zastanów się nad dowiązaniem symbolicznym /home/paul/fstab
wskazującym na /etc/fstab
. Znajdują się one na dwóch różnych woluminach, których system Windows - jeśli jest w stanie zobaczyć je za pośrednictwem sterownika systemu plików (który działa!) - nie może powiedzieć, że należą do siebie w sposób /etc/fstab
opisany. Tak więc link, który Windows zobaczyłby pod folderem \paul\fstab
, nawet jeśli byłby przetłumaczony, wskazywałby na to \etc\fstab
, co nie istnieje /dev/sda2
. A jeśli to dowiązanie symboliczne wskazywałoby na względną ścieżkę ../../etc/fstab
, nic by się nie zmieniło.
Istota: Tak więc, chociaż można sobie wyobrazić, że można to uruchomić w niektórych przypadkach narożnych, fakt, że semantyka i składnia różnią się po obu stronach ogrodzenia, uniemożliwia znalezienie praktycznej i ogólnej metody, która działa.
ntfs
obsługuje punkty montowania (jeśli nie lubisz wszystkich tych liter).
Odpowiedź 0xC0000022L jest dokładna po stronie systemu Windows. Mac rozpoznaje dowiązania symboliczne Linuksa; jednak Linux nie rozpoznaje aliasów utworzonych w Finderze Maca (dowiązania symboliczne utworzone za pomocą ln -s działają dobrze).
.lnk
pliki).