Czy jest jakaś możliwa sytuacja, kiedy
ls -l file.txt
pokazuje inną liczbę bajtów niż
wc -c file.txt
W jednym skrypcie znalazłem porównanie tych dwóch wartości. Co może być tego przyczyną? Czy to możliwe, aby mieć różne liczby bajtów tego samego pliku?
Odpowiedzi:
Tak, są takie przypadki.
W przypadku dowiązań symbolicznych w systemie Linux z GNU
ls
,ls -l
wypisze rozmiar łącza, a jednocześniewc -c
rozwiąże rzeczywisty plik i odczyta tam liczbę bajtów. Poniżej widać, żels -l
raportuje 29 bajtów, podczas gdywc
raportuje 172 bajty w rzeczywistym pliku.W przypadku wirtualnych systemów plików , takich jak
/proc
lub/sys
, wiele plików będzie miało rozmiar 0ls -l
. W/dev
systemie plików mamy wiele specjalnych plików, takich jak urządzenia znakowe i urządzenia blokowe -wc -c
zawiesza się na nich ils -l
pokazuje większe i mniejsze liczby zamiast wielkości.Nazwane potoki będą zgłaszane jako
0
bajty przezls -c
, ale wwc -c
rzeczywistości odczytują zawartość potoku, więc technicznie powie ci, ile danych jest w nazwanym potoku:W przypadku zwykłych plików rozmiar powinien być równy.
Punkt
ls -l
awc -c
, i jak one działają także różni.wc -c
faktycznie otwiera plik do odczytu (możesz to zobaczyć, jeśli uruchomiszstrace wc -c /etc/passwd
na przykład).ls -l
wykonuje tylkostat()
połączenia na tych. Wyjaśnia to również, dlaczego w/proc
ls -l
programach pokazuje rozmiar 0 - nie można statystyki tych plików, ponieważ nie są one „prawdziwe” lub faktycznie przechowywane na dysku twardym / ssd.wc -c
zamiast tego odczytuje zawartość tego pliku i oblicza jego rozmiar.Wreszcie
ls -l
jest tylko narzędziem do interaktywnego wyświetlania pozycji. Rzadko nadaje się do pisania skryptów. Gdy rzeczywiście potrzebujesz odczytać dane, użyjwc -c
zamiast tego.Należy pamiętać, że do pisania skryptów i oceny rozmiaru pliku
ls
nie jest najlepszym kandydatem. W rzeczywistości jest to jedna z powszechnych praktyk unikania analizowanials
wyników . Użyj,du -b
aby sprawdzić rozmiar pliku.źródło
/sys/
,/proc/
itp.) Mogą dostarczyćstat
informacji, jeśli realizator zdecyduje się na to. Przez większość czasu nie ma ważnego powodu, więc zostało to pominięte. Przykłady obejmują,/proc/kcore
która jest zgłaszana jako rozmiar adresowalnej pamięci jądra (zwykle znacznie więcej niż dostępna pamięć fizyczna).ls -l
zwróci rozmiar pliku zgłaszanego przez system plików.wc -c
spróbuje odczytać plik, aby określić „rzeczywisty” rozmiar. Z moich obserwacji wynika, że najpierw próbuję szukać do końca, a jeśli to nie zadziała, odczyta cały plik, licząc rozmiar w miarę upływu czasu.Jest to prosty opis tego, co robią te dwa narzędzia, ale prowadzi do szeregu implikacji dla wyników:
ls
da niepoprawne wyjście dla niektórych systemów plików. Na przykład zwirtualizowane systemy plików, takie jak,/proc
będą zgłaszać rozmiar zero dla wielu plików, ponieważ te „pliki” nigdzie nie są fizycznie przechowywane; są generowane zgodnie z wymaganiami oprogramowania.wc
nie będzie w ogóle działać w przypadku plików bez uprawnień do odczytu, alels
wymaga tylko uprawnień do wyświetlenia katalogu (porównajls -l /etc/shadow
zwc -c /etc/shadow
).Jak wspomniano w innych odpowiedziach, zachowanie linków symbolicznych jest również inne. Ponieważ
wc
próbuje je odczytać, kończy się odczytaniem pliku, do którego wskazuje dowiązanie symboliczne, a ponieważls
po prostu odpytuje system plików, zgłosi rozmiar użyty do przechowywania samego dowiązania symbolicznego.Jestem pewien, że istnieją jeszcze inne różnice, o których jeszcze nie pomyślałem, ale pomyślałem, że podam jasne i proste wyjaśnienie podstawowego powodu tych różnic.
źródło
seek()
. Wydaje się, że tak jest po uruchomieniustrace wc -l
na kilku dużych plikach.Dla normalnego pliku, statystyki wywołań ls i wc. Jednak dla pliku / proc lub / sys ls zwraca 0, ale wc zwraca inną liczbę:
Jest to prawdopodobnie sposób na sprawdzenie, czy coś jest plikiem specjalnym.
źródło
wc -c
dla mnie przynajmniej dzwonifstat
, ale pozornie do innych celów. Znajduje długość pliku,lseek
docierając do końca. W przypadku, gdy zwraca błąd,read
jest to cały plik.