Ännu mer som inte verkar stämma i ls...

[Osprey]

Förutom utskrifter från ls som ger tveksamt format för utskrifter, så verkar det som om ls inte har riktig koll på storleken på filer heller.

Till exempel så har jag en fil som är 10742183424 bytes enligt utskrift från "ls -l" och så långt är allt gott och väl och jag tror på att ls har rätt där. En annan fil är 4795338240 och det är säkert rätt det med.

Tittar jag på den i Nautilus så säger den att den ena filen är 4,5 GB och den andra 10,0 GB och det verkar mycket sannolikt också.

Om jag däremot tittar på dem med "ls -lh", så säger ls att de är 4,5 G respektive 11 G och 4,5:an kan jag väl gå med på där, medan 11:an däremot är mer tveksam...

Tittar jag istället på dem med "ls -l --si" så får jag istället 4,8 G för den ena, medan den andra fortfarande är 11 G.

Oavsett hur jag försöker få till det här med 1024 respektive 1000, så kan jag bara inte få det här till att stämma...

Så, det verkar som om det är klara problem med den variant av ls som finns i GNU Coreutils...

[dmz]

Är det detta du har råkat ut för? http://www.ubuntu-se.org/phpBB3/viewtop ... 29&start=0

[Osprey]

Är det detta du har råkat ut för? http://www.ubuntu-se.org/phpBB3/viewtop ... 29&start=0

Jag tror inte det, det verkar också vara så att ls i motsats till Nautilus inte följer normala avrundningsregler, utan istället konsekvent avrundar uppåt.

På ett sätt kan det kanske vara rätt när det gäller lagringsutrymme, det vill säga att storleken är minst det som anges. Men det kan ju också bli ganska stor differens mot verkligheten när avrundningen sker till närmast större jämna gigabyte, eller kanske ännu värre vid större storlekar.

Problemet verkar dock bara uppstå när ls ska "snygga till det hela" med "ls -lh" och "ls -l --si", siffran vid vanlig "ls -l" är säkert helt korrekt. Så egentligen hade det kanske varit helt ok, om det hade stått i man-sidan att ls alltid avrundar uppåt i dessa lägen och att diffen gentemot verkligheten kan bli uppemot en gigabyte eller egentligen uppemot en enhet i den enhet som anges...

[Konservburk]

Om jag däremot tittar på dem med "ls -lh", så säger ls att de är 4,5 G respektive 11 G och 4,5:an kan jag väl gå med på där, medan 11:an däremot är mer tveksam...

Tittar jag istället på dem med "ls -l --si" så får jag istället 4,8 G för den ena, medan den andra fortfarande är 11 G.

Oavsett hur jag försöker få till det här med 1024 respektive 1000, så kan jag bara inte få det här till att stämma...

Så, det verkar som om det är klara problem med den variant av ls som finns i GNU Coreutils...

Det är egentligen inget konstigt, utan betyder bara att din fil inte får plats på endast 10G. Med ls -lh så kommer allting som är större än 10G och mindre än eller exakt lika med 11G att visas som 11G.

10*(2^30) visas som 10G
10*(2^30)+1 visas som 11G
11*(2^30) visas som 11G
11*(2^30)+1 visas som 12G

Det är samma sak med ls -l --si med skillnaden att du då har 10^9 istället för 2^30.

Det är inte bara ls -lh som uppför sig på det här sättet. Även du -bh fungerar likadant, och förmodilgen också en del annat i corutils.

[Osprey]

Ja och det är egentligen inte alls ologiskt när man betänker det som erforderligt lagringsutrymme...

Men på man-sidan står det bara:

Kod: Markera allt

       -h, --human-readable
              with -l, print sizes in human readable format (e.g., 1K 234M 2G)

       --si   likewise, but use powers of 1000 not 1024

det kunde stått i man-sidan att avrundning alltid sker uppåt...
speciellt som Nautilus verkar avrunda enligt vanlig praxis...

[Osprey]

Jag provade förresten med Dolphin och Konqueror också och de avrundar på precis samma sätt som Nautilus dvs. enligt vanliga avrundningsregler. Så i det här sammanhanget är det "ls" som skiljer sig lite och oavsett vilket man anser vara rätt, så kan det vara bra att ha i åtanke...

[pun]

Jo men har man problem det detta så filar man väl en bugg hos Ubuntu eller kanske eller hellre direkt till "uppström"

[Osprey]

Jo men har man problem det detta så filar man väl en bugg hos Ubuntu eller kanske eller hellre direkt till "uppström"

Någon bugg är det ju som jag förstått det uppenbarligen inte, det är två olika sätt att se samma sak och då kommer man in på en snarast filosofisk frågeställning...

Enda buggen isåfall är att det inte står på man-sidan att ls med "-h" eller "--si" alltid avrundar uppåt...

[pun]

Jo men har man problem det detta så filar man väl en bugg hos Ubuntu eller kanske eller hellre direkt till "uppström"

Någon bugg är det ju som jag förstått det uppenbarligen inte, det är två olika sätt att se samma sak och då kommer man in på en snarast filosofisk frågeställning...

Enda buggen isåfall är att det inte står på man-sidan att ls med "-h" eller "--si" alltid avrundar uppåt...

Jo då kan jag inte se något som helst problem i detta !

[Konservburk]

Jag grävde runt lite i källkoden och hittade funktionen som har hand om det här. Den ser ut att klara av såväl avrundning uppåt som neråt och även till närmaste:

http://git.savannah.gnu.org/cgit/gnulib ... man.c#n119

human_round_to_nearest används bara av dd.

human_floor används bara av shred.

human_ceiling används av shred, sum, df, du och ls.

[Osprey]

Jag grävde runt lite i källkoden och hittade funktionen som har hand om det här. Den ser ut att klara av såväl avrundning uppåt som neråt och även till närmaste:

http://git.savannah.gnu.org/cgit/gnulib ... man.c#n119

human_round_to_nearest används bara av dd.

human_floor används bara av shred.

human_ceiling används av shred, sum, df, du och ls.

Mycket intressant att läsa och se verkligheten bakom det hela och det finns säkert en genomtänkt anledning till att olika kommandon använder olika typer av avrundning.

Så det enda jag kan invända mot det är att det hade känts bra om ls hade visat samma siffra för storlek som de grafiska varianterna.

I ett script borde detta dock inte vara något problem, eftersom man då sannolikt utgår ifrån storleken i bytes och då kan avrunda så som man själv vill. Om man nu trots vad som nyss sades i en annan tråd (se längst upp) använder utskrifter från ls alltså...

[dmz]

För det så passar nog stat (coreutils) eller stat ( man 3 stat ) eller stat ( perldoc -f stat ) bättre. Det räknar garanterat rätt.