Czy używasz skrzynek na twarde linki? [Zamknięte]

W jakich sytuacjach chciałoby się użyć twardego linku zamiast miękkiego linku? Osobiście nigdy nie spotkałem się z sytuacją, w której chciałbym użyć twardego linku zamiast miękkiego linku, a jedynym przypadkiem, z jakim się spotkałem podczas przeszukiwania sieci, jest deduplikacja identycznych plików .

Oprócz użycia kopii zapasowej wymienionego w innym komentarzu, który moim zdaniem obejmuje również migawki na woluminie BTRFS, przypadek użycia twardych linków nad miękkimi linkami to kolekcja plików sortowana według znaczników. (Niekoniecznie najlepsza metoda tworzenia kolekcji, metoda oparta na bazie danych jest potencjalnie lepsza, ale w przypadku prostej kolekcji, która jest względnie stabilna, nie jest tak źle).

Zbiór multimediów, w którym wszystkie pliki są przechowywane w jednym, płaskim katalogu i są sortowane w innych katalogach na podstawie różnych kryteriów, np .: roku, tematu, wykonawcy, gatunku itp. Może to być osobista kolekcja filmów lub kolektyw komercyjnego studia Prace. Zasadniczo plik został zapisany, prawdopodobnie nie będzie modyfikowany i sortowany, być może w wielu lokalizacjach według łączy.

Należy pamiętać, że pojęcia „oryginał” i „kopia” nie mają zastosowania do twardych linków: każdy link do pliku jest oryginałem, w normalnym sensie nie ma „kopii”. Jednak w opisie przypadku użycia terminy naśladują logikę zachowania.

„Oryginał” jest zapisywany w katalogu „katalog”, a posortowane „kopie” są na stałe połączone z tymi plikami. Atrybuty plików w katalogach sortowania można ustawić na r / o, zapobiegając przypadkowym zmianom nazw plików i struktury posortowanej, podczas gdy atrybuty katalogu katalogu można zmienić na r / w, umożliwiając jego modyfikację w razie potrzeby. (Przykładem mogą być pliki muzyczne, w których niektóre odtwarzacze próbują zmieniać nazwę i reorganizować pliki na podstawie znaczników osadzonych w pliku multimedialnym, z danych wprowadzonych przez użytkownika lub z Internetu). Dodatkowo, ponieważ atrybuty katalogów „kopiuj” mogą być inne niż „oryginalny” katalog, posortowana struktura może zostać udostępniona grupie lub światu z ograniczonym dostępem, podczas gdy główny „katalog” jest dostępny tylko dla głównego użytkownika, z pełnym dostępem. Same pliki jednak zawsze będą miały te same atrybuty we wszystkich linkach do tego i-węzła. (ACL można zbadać, aby to poprawić, ale nie moją dziedzinę wiedzy.)

W przypadku zmiany nazwy oryginału lub przeniesienia (na przykład pojedynczy katalog „katalog” staje się zbyt duży, aby nim zarządzać), twarde linki pozostają ważne, miękkie linki są zepsute. Jeśli „kopie” zostaną przeniesione, a miękkie linki są względne, wówczas miękkie linki ponownie zostaną zerwane, a twarde linki nie będą.

Uwaga: wydaje się, że istnieje niespójność w sposobie, w jaki różne narzędzia zgłaszają użycie dysku, gdy w grę wchodzą miękkie linki. W przypadku twardych linków wydaje się to jednak spójne. Zatem przy 100 plikach w katalogu posortowanych w zbiór „znaczników” można łatwo połączyć 500 „kopii”. (W przypadku kolekcji fotografii, powiedzmy datę, fotografa i średnio 3 tagi „tematyczne”). Na przykład Dolphin zgłosi to jako 100 plików dla twardych linków i 600 plików, jeśli zostaną użyte miękkie linki. Co ciekawe, raportuje to samo użycie miejsca na dysku w obu kierunkach, więc wygląda na dużą kolekcję małych plików dla miękkich linków i małą kolekcję dużych plików dla twardych linków.

Jedynym zastrzeżeniem dla tego rodzaju przypadków użycia jest to, że w systemach plików korzystających z COW, modyfikacja „oryginału” może przerwać twarde dowiązania, ale nie przerwać miękkich dowiązań. Ale jeśli celem jest przygotowanie kopii wzorcowej, po edycji, zapisaniu i posortowaniu COW nie wchodzi w scenariusz.

Twarde linki są przydatne w przypadkach, gdy nie chcesz wiązać istnienia obu plików. Rozważ to:

touch a
ln -s a b
rm a

Teraz bjest bezużyteczny. (I te kroki mogą się zdarzyć dość daleko od siebie, mogą być wykonywane przez różnych ludzi itp.)

Podczas gdy z twardym linkiem

touch a
ln a b
rm a

b jest nadal obecny i poprawny.

Pojedynczy program może zmienić swoje zachowanie w zależności od nazwy uruchomionej jako:

$ ls -li `which pgrep` `which pkill`
208330 -r-xr-xr-x  2 root  bin  19144 Jul 26  2016 /usr/bin/pgrep
208330 -r-xr-xr-x  2 root  bin  19144 Jul 26  2016 /usr/bin/pkill

Które w źródle decyduje się przez coś takiego

if (strcmp(__progname, "pgrep") == 0) {
    action = grepact;
    pgrep = 1;
} else {
    action = killact;

jednak dokładne szczegóły będą się różnić w zależności od systemu operacyjnego i języka.

Pozwala to (w większości) na identyczny kod, aby nie trzeba było go kompilować do dwóch (głównie) identycznych plików binarnych. Należy pamiętać, że unix datuje się na dni, kiedy miejsce na dysku było bardzo drogie, choć według Stevensa w APUE rozdział 4 dowiązania symboliczne zostały zaimplementowane w BSD4.2 (1983) w celu zastąpienia różnych ograniczeń dowiązań twardych. Program testowy, aby sprawdzić, czy nazwa dowiązania symbolicznego jest używana jako nazwa programu, może wyglądać mniej więcej tak:

#include <stdio.h>
#include <stdlib.h>
int main(int argc, char *argv[])
{
    printf("called as '%s'\n", *argv);
    exit(0);
}

I przetestowane przez:

$ cc -o myname myname.c 
$ ln -s myname alias
$ ./myname
called as './myname'
$ ./alias
called as './alias'
$ 

Kiedy moje oprogramowanie P2P kończy pobieranie określonego pliku, plik jest umieszczany w określonym katalogu. Pobrane pliki prawie nigdy nie wymagają edycji. Często zdarza się, że tworzę dowiązanie twarde w innym katalogu, w którym powinien znajdować się plik.

Zalety:

• Nadal udostępniam plik w sieci P2P tak, jak powinienem, nawet jeśli ja rmlub mv„kopia”.
• Plik znajduje się również na ścieżce, w której go potrzebuję; większość takich lokalizacji nie jest udostępniana.
• Mogę rm„oryginał”, aby zatrzymać udostępnianie pliku; ta operacja nie wpływa na „kopiowanie” w żądanym miejscu.
• Moje miejsce na dysku jest używane tylko raz.

Główny punkt: gdybym wiedział z góry, który plik chciałbym rmnajpierw, mógłbym przejść do dowiązania symbolicznego. Ale ja nigdy nie wiem.

Systemy plików to prosty, a jednocześnie skuteczny sposób organizowania i klasyfikowania plików (jest to ich główny powód istnienia). Linki twarde pozwalają na większą elastyczność w tej kwestii.

Jak wspomniano, nie ma koncepcji oryginału i kopii w przypadku twardych dowiązań, wszystkie pozycje katalogu (dowiązania twarde) są po prostu odniesieniami do istnienia pliku (wskazują na jego i-węzeł) bez pierwszeństwa, dlatego też nie ma żadnych uszkodzonych dowiązań twardych. .

Oto kilka przypadków użycia, w których występują twarde linki, ale miękkie linki nie :

1. Wyobraź sobie, że masz kolekcję filmów, muzyki lub innych mediów i chcesz zastosować inne kryteria klasyfikacji, na przykład utwory sklasyfikowane przez artystę w oddziale (każdy artysta ma własny podkatalog); według gatunku w innej gałęzi (każdy w innym podkatalogu) itp. Nadal nie chcesz duplikować plików ani decydować, gdzie umieścić „oryginał”, abyś miał swobodę przeklasyfikowania bez konieczności „ zarządzaj ”i ponownie łącz pliki podczas przenoszenia, aby uniknąć niedziałających łączy.

2. Innym powodem jest uniknięcie marnotrawstwa przestrzeni dyskowej, która byłaby wymagana do posiadania wielu kopii tego samego pliku, a jednocześnie pozwoliła chrootsystemowi korzystać z podzbioru plików w katalogu głównym „głównego” systemu plików (dowiązania symboliczne nigdy nie mogłyby odwoływać się do plików z zewnątrz) chrootpiaskownicy, nawet jeśli mają one ścieżek względnych).

3. Innym bardzo ważnym, ale rzadko wymienianym powodem istnienia linków twardych są ..podkatalogi. Te ..katalogi faktycznie są (w większości UNIX fs implementacje) hardlinki do katalogu nadrzędnego, bez hardlinki to musi być realizowane w zupełnie inny sposób, podczas gdy istnienie hardlinki sprawia, że to bardzo łatwe do wdrożenia.

Bardzo powszechny przykład w świecie rzeczywistym, który wymaga linków:

git clone --reference <repository>

To klonuje z lokalnego repozytorium Git z niemal zerowym kopiowaniem. Zamiast kopiować pliki obiektowe (niezmienne pliki używane przez Git do „bazy danych”), po prostu łączy je na stałe.

Każde repo może usunąć obiekt, ale i-węzeł pozostaje ważny przez resztę repo. A jeśli obiekt zostanie usunięty ze wszystkich repozytoriów, zostanie usunięty z dysku. Twarde linki tworzą wyjątkowo solidne i szybkie rozwiązanie. Bardzo często na serwerach CI.

Istnieje wersja non-hard-link: git clone --shared <repository>. Jest to jednak kapryśne i ma o wiele więcej zastrzeżeń, ponieważ wszyscy pracują nad tym samym katalogiem.

Niedawno miałem przypadek użycia nieco bezpiecznej procedury aktualizacji dla systemów opartych na U-Boot, gdzie uImagejest miękkie łącze wskazujące obraz do uruchomienia, pomysł polegał na tym, że przerwa w zasilaniu nie powinna powodować problemów, bez względu na to, w którym momencie proces się dzieje (zakładając, że system plików gra razem):

ln image.bin backup_image.bin
ln -sf backup_image.bin uImage

// replace image.bin

ln -sf image.bin uImage
rm backup_image.bin

Bez linków nie byłoby to takie proste.

/edytować:

Dzięki komentarzom wiem teraz, że lepiej byłoby zrobić:

ln image.bin backup_image.bin
ln -sf backup_image.bin uImageNew
mv uImageNew uImage || rm -rf uImage && mv uImageNew uImage

// replace image.bin

ln -sf image.bin uImageNew
mv uImageNew uImage || rm -rf uImage && mv uImageNew uImage
rm backup_image.bin

( rmJest tutaj, aby móc lepiej uciec od dziwnego stanu, np. Jeśli uImagejest to coś nieoczekiwanego, co spowodowałoby mvniepowodzenie [ale niekoniecznie poprzednie ln -sfrozwiązanie]).

Jednym z moich zastosowań twardych linków jest pobieranie lub dekompresowanie uszkodzonego pliku. Program, który pobiera lub rozpakowuje (np. Rozpakuj lub rozpakuj) często automatycznie usuwa niekompletny plik, gdy napotka błąd, i zwykle nie ma opcji, aby go zatrzymać. Jeśli chcę zachować plik, mogę utworzyć twardy link do niego.

BackupPC to system tworzenia kopii zapasowych, który wykorzystuje twarde łącza na serwerach w celu zapewnienia deduplikacji na poziomie plików.

Pliki są najpierw przechowywane w drzewie katalogów „pula” na podstawie ich skrótu md5. Każda kopia zapasowa, która korzysta z tego pliku, tworzy stałe łącze do pliku puli. Gdy kopie zapasowe wygasają / są usuwane, ich twarde łącza są usuwane z systemu plików.

Linki twarde są lepsze od linków miękkich, ponieważ zapewniają automatyczne zliczanie referencji. Zadanie cron okresowo usuwa wszystkie pliki w katalogu puli, które nie mają więcej niż jednego łącza.

Ta metoda ma pewne wady (przede wszystkim trudność w użyciu narzędzi opartych na systemie plików do replikacji magazynu kopii zapasowych), ale w praktyce okazała się dość solidna.

Kolejny przypadek użycia: serwer aplikacji WWW tomcat java traktuje nazwy plików jako metadane. Plik „wojny” java musi zostać nazwany na podstawie ścieżki na serwerze WWW.

np .: foo.war jest kodem Java, który obsługuje adres URL/foo

Niestety rozwiązuje dowiązania symboliczne przed podjęciem tej decyzji.

Powiedzmy, że chcesz wdrożyć kompilację aplikacji i nadaj jej opisową nazwę pliku (np. Z numerem lub datą wydania). Nie możesz utworzyć dowiązania symbolicznego do pliku o „prawdziwej” nazwie - musisz utworzyć dowiązanie stałe.

foo.wardowiązanie symboliczne do foo-20170129.warnie działa

foo.warhardlinkowane do foo-20170129.warutworów.

Nie podoba mi się to zachowanie kocurów, ale linki dające mi do obejścia.