Dowiązania (linki) twarde do plików - kilka pytań


(Quentin) #1

Witam!

Mam kilka pytań odnośnie tzw. dowiązań (linków) twardych do różnych plików. Przeczytałem o tym w najnowszym KŚ Ekspercie na str. 55:

Pytanie 1:

O co chodzi z tym, że plik = porcja danych, do których przyporządkowane jest jedno dowiązanie symboliczne ? Jeżeli wziąć to dosłownie to przy przenoszeniu/kopiowaniu pliku nie można było by go potem otworzyć - dowiązanie symboliczne jest związane tylko z plikiem w danej ścieżce dostępu…

Pytanie 2:

O jaki pierwszy twardy link i wyróżnienie chodzi ?

Pytanie 3:

Nie rozumiem też o co chodzi z tym, że twarde linki odsyłają do zbioru danych na dysku, a nie do ścieżek. Czy ktoś mógłby mi wytłumaczyć różnicę pomiędzy tymi dwoma pojęciami i podać jakiś prosty przykład ?

Z góry dzięki za pomoc.


(Grzegorz Kwiatek) #2

Witam,

Jeśli zajmujesz się programowaniem np. w C++, to wydaje mi się, że najlepszym opisem “twardego” linku byłby “inteligentny wskaźnik”. Inteligentny, tzn. taki który zawiera w sobie informację ile innych podobnych mu wskaźników wskazuje na określony obiekt.

  1. Wspomnienie słowa “symboliczne” nie jest trafione i powoduje zrozumiałe zamieszanie u czytającego.

  2. Silenie się na tworzenie rzeczywistości na potrzeby artykułu gdy można to opisać prościej. Pewnie chodzi o to, że autor uważa, że są “normalne” pliki i “twarde linki”. Tymczasem granica pomiędzy czymś co nazywamy “twardym linkiem” a “normalnym plikiem” wydaje się nie być wyraźna i pewnie zależy od systemu plików.

  3. Ja to rozumiem tak:

a) Plik jest tworzony w jakiejś lokalizacji na dysku (w alternatywnej rzeczywistości C++ byłby to ADRES jakiegoś obiektu w pamięci utworzony np. operatorem “new”)

b) tworzymy twardy link do pliku (w alternatywnej rzeczywistości C++ tworzymy WSKAŹNIK do którego przypisujemy wspomniany ADRES). Teraz do zawartości możemy się odwoływać bez problemu, podobnie jak w C++ możemy się odwoływać do danego obiektu przez wskaźnik do niego. Gdzieś dodatkowo jest umieszczana informacja, że do pliku (obiektu w naszym przykładzie a la C++) wskazuje JEDEN twardy link (tzn. jeden wskaźnik).

c) jeśli stworzymy kolejny twardy link, to gdzieś modyfikowana jest informacja ILE twardych linków (wskaźników w C++) obecnie wskazuje na dany plik (na początku jest zawsze teoretycznie JEDEN wskaźnik - o to pewnie chodziło w pytaniu 2).

d) jeśli usuniemy jakiś twardy link, to wspomniany licznik odwołań do pliku jest pomniejszany. Jeśli okaże się, że licznik jest =0, to plik jest usuwany.

Mam nadzieję, że rozjaśniłem nieco…


(Quentin) #3

OK, dzięki - rozjaśniło mi to znacznie sprawę :wink:

Jeszcze mam tylko pytanie odnośnie #3 - skoro te twarde linki możemy porozrzucać po różnych folderach (w obrębie 1 partycji, bo w przypadku twardych linków nie da się poza nią) i dalej będą one wskazywały na poprawny plik, to wychodzi na to, że ta zawartość tego pliku na dysku nie przemieszcza się razem z twardymi linkami, prawda :?:

Nie ważne, do jakich folderów wpakujemy twarde linki - plik na który pokazują zawsze będzie fizycznie na dysku w tym samym miejscu :?:


(Grzegorz Kwiatek) #4

Dokładnie tak. Wg. mojej wiedzy (ostatnio dokształcałem się w tym temacie dla systemu NTFS) tak właśnie to działa: plik sobie siedzi w jednym miejscu, a twarde linki mogą wędrować w obrębie jednej partycji.

Polecam lekturę tej strony: http://schinagl.priv.at/nt/hardlinkshellext/hardlinkshellext.html. Polecam też, jeśli używasz NTFS, zainstalowanie umieszczonego na tej stronie rozszerzenia do powłoki. Znacznie ułatwia sprawę…


(Quentin) #5

Chodziło Ci o tą stronę:

:arrow: http://schinagl.priv.at/nt/hardlinkshel … llext.html

:?:

Bo dałeś mi jakiś link do pliku z dysku chyba :stuck_out_tongue:


(Grzegorz Kwiatek) #6

Ech, oczywiście. Nawet nie zobaczyłem że link z cache… Wyedytowałem.


(Quentin) #7

OK, mam jeszcze ostatnie pytanie odnośnie tych linków. W artykule jest napisane, że:

Nie wiem czy nie jest to zmyślone. Przecież gdy otworzę np. skrót do pliku _ obraz.jpg _ to będę pracował właśnie na tym pliku czyli na oryginale. Mogę też skróty otwierać w programach, jeżeli np. trzeba coś wczytać z pliku _ *.txt _, to otwieram skrót do niego. Nie wiem więc, dlaczego niby większość programów nie umie ich wykorzystać…


(Grzegorz Kwiatek) #8

Szczerze mówiąc nie ja także nie mogłem dotychczas znaleźć różnicy pomiędzy “Skrótami do…” a linkami symbolicznymi (rozważam to dla systemu Windows).

Ale znalazłem teraz na szybko to:

http://en.wikipedia.org/wiki/Symbolic_link

… i rozdział o “Shortcuts” - jest tam kilka różnic opisane pomiędzy skrótami a linkami symbolicznymi. Właśnie się wczytuję.

Edit:

Cytowana przez Ciebie różnica jest tam wspomniana. Ale chyba najważniejsze jest to:


(Lol600000065) #9

tez mam pytanie odnośnie tych skrotow i linków w takim razie.

skoro skrot moze sie odwoływac i do folderów i do plikow, wychodzic poza partycje (tzn element docelowy jest na innej partycji a skrot na innej), a dodatkowo po zmianie lokalizacji przez element docelowy skrot sam go “szuka” to dlaczego warto używać linków ? Z nimi jest przecież tylko więcej roboty… trzeba uzywac niewygodnych komend w cmd… jest jedno narzedzie GUI ktore tworzy tzw. połaczenia (ang. junctions), ale te z kolei maja jeszcze wiecej ograniczen niz symlinki (nie moga odwoływac sie do plikow tylko do folderów)…


(Grzegorz Kwiatek) #10

Skróty i twarde linki - każdy ma wady i zalety jak dla mnie. Nie odnoszę się do linków symbolicznych , bo ich nie używam.

Skrót - może odwoływać się do dowolnego elementu, także poza systemem plików. Ale jeśli się “zgubi” element docelowy, to system go musi szukać. Poza tym zwróć uwagę, że skrót jest sam w sobie plikiem (*.lnk), co nie jest bez znaczenia zapewne dla wydajności całego systemu. Tysiąc skrótów (oczywiście przesadzam) do jednego elementu na pewno nie zwiększa wydajności systemu plików.

Twardy link - jest bardzie “reliable” dla systemu operacyjnego i użytkownika - zawsze pozwala dostać się do elementu na który wskazuje, tzn. nigdy nie będzie złamany. Poza tym nie zajmuje miejsca w systemie plików , bo jest z nim zintegrowany (oczywiście płacimy za to niemożnością wyjścia poza dany system plików). Nawet nie zdajemy sobie sprawy że system Windows wykorzystuje twarde linki bardzo intensywnie (vide folder WINSXS w systemie VISTA związany z mechanizmami windows update).

Natomiast co do “Junctions” to sobie je bardzo chwalę jako programista - czasami zamiast długich ścieżek wolałbym mieć krótsze, w jednym miejscu chciałbym zebrać wszystkie katalogi z plikami nagłówkowymi. Połączenia też się sprawdzają np. w takim programie jak DROPBOX, gdy chcesz archiwizować jakieś zewnętrzne lokalizacje (program ten domyślnie archiwizuje jeden wybrany folder).

To takie moje przemyślenia jako użytkownik.


(Lol600000065) #11

No OK, a dlaczego np. nie klikniesz prawym przyciskiem myszy na folder i dasz ‘utworz skrot’ i przeciagniesz skrot w odpowiednie miejsce tylko będziesz korzystał z niewygodnej konsoli cmd czy tam aplikacji Junction Link Magic ? wszystko po to zeby zaoszczedzic na rozmiarze skrotu :?:

no chyba ze rzeczywiscie duzo aplikacji nie umie korzystac ze skrotow (wg cytatu Quentina ), ale ja sie jeszcze jakos z tym nie spotkałem nigdy…


(Grzegorz Kwiatek) #12

A sprawdziłeś to co napisałem? Np. Dropbox NIE sychronizuje katalogów przez skróty, natomiast junctions działają prawidłowo. Także mój Borland Developer Studio NIE interpretuje skrótów do katalogów prawidłowo, za to junctions pracują prawidłowo… To nie są stare programy. Jeśli chodzi o proste “codzienne” zastosowania, gdy używa się skrótów jako… skrótów, to pewnie że junctions się nie przydają. Ale w wielu profesjonalnych zastosowaniach - tak. Zapewniam Cię, mogę znaleźć jeszcze wiele takich aplikacji które nie będą działać prawidłowo ze skrótami.