Permalänk
Avstängd

Nautilus och värdesiffror

Något jag stört mig på läääänge utan att hitta en lösning på är ett beteende i nautilus som jag rentav skulle vilja kalla för bugg.

Nämligen en inkonsekvent presentation av decimaler i filstorlekar.

Ungefär såhär fungerar det (notera att Nautilus använder SI-prefix, alltså 1 kB = 1000 byte, inte 1 kiB = 1024 byte! Det är INTE "problemet".):

Filstorlek (byte) Rapporterad storlek Borde vara 999 999 byte 999 byte 1000 1 kB 1.000 kB 1023 1 kB 1.023 kB 999999 1000.0 kB 999.9 kB 1000000 1 MB 1.000 MB 999999999 1000.0 MB 999.9 MB 1000000000 1 GB 1.000 GB 1073741824 (1 GiB) 1.1 GB 1.074 GB

Nautilus är alltså sjukt inkonsekvent med antalet värdesiffror, från 1 till 5 stycken. *Givetvis* ska samma antal värdesiffror ALLTID användas.

Observera att detta INTE är en fråga om att blanda ihop GB med GiB eller liknande, jag frågar INTE om varför 1000 rapporteras som kB i stället för 1024 eller liknande, jag är väl införstådd i skillnaderna här.

Jag tycker det här beteendet i inkonsekvens av användandet av värdesiffror är groteskt. Google har inte varit till någon hjälp.

Visa signatur

http://www.theatlantic.com/national/archive/2012/05/how-the-p...
"If there's a simple lesson in all of this, it's that hoaxes tend to thrive in communities which exhibit high levels of trust. But on the Internet, where identities are malleable and uncertain, we all might be well advised to err on the side of skepticism."

Permalänk
Medlem

Och?

Eller vill du ha standardsvaret "Du har källkoden så fixa problemet".

Permalänk
Medlem

Tja, är det så självklart att Nautilus borde presentera siffrorna med samma antal värdesiffror alltid? Jag tror att för snittanvändaren av Nautilus så kommer det bara att förvirra mer än att hjälpa tyvärr. Och jag antar att skaparna av Nautilus vill bygga en lättanvänd filhanterare snarare än att skapa en fullt korrekt sådan, på gott och ont.
Och vill man veta den exakta filstorleken så kan man ju alltid högerklicka och välja egenskapaer/properties och där se både den rapporterade storleken, och den exakta storleken i byte.

Men ja, vissa märkligheter verkar det finnas i avrundningen. De verkar köra med att ta bort .0, och att det går från 1 (ej 1.0) till 1.1 till 1.2 och liknande. Men varför får då exempelvis 999999 byte en ".0" efter 1000 kB, när 1023 byte inte får en ".0" efter 1 kB?

Sen, har du inte några fel i din tabell under "Borde vara"?
Ska inte 999 byte bli 999.0 byte om det ALLTID ska vara fyra värdesiffror, trotts att decimaler av byte inte finns?
Och 999999 byte och 999999999 i fyra värdesiffror verkar du ha avrundat fel. Det blir inte 999.9 kB/999.9 MB. Det ska avrundas till 1000 kB/1000 MB alternativt 1.000MB/1.000GB.

Permalänk
Avstängd
Skrivet av aluser:

Och?

Eller vill du ha standardsvaret "Du har källkoden så fixa problemet".

Och - problemet är att det är inkonsekvent och gör det svårare att jämföra filstorlekar. Det är dessutom objektivt sett ett felaktigt sätt att hantera värdesiffror, förutom att det ser fördjävligt ut.

"Standardsvaret" är ju inte mycket till hjälp. Jag föreställde mig att detta hanterades i skript eller i inställningsfiler. Är det hårdkodat i källkoden är det förstås extra dumt och problematiskt. Visst, jag skulle kunna ladda hem källkoden, fixa problemet för mig själv, men det skulle ju inte vara en lösning. Varje uppdatering skulle paja det igen. Jag är inte med i någon community, är inte linux-utvecklare och kan/vill därför inte ladda upp saker "upstream". Ett betydligt vettigare svar hade varit att berätta var eller till vem man rapporterar detta och kanske funderingar på varför ingen reagerat på åratal på detta idiotiska beteende i Nautilus.

Slutsatsen, nej, jag vill inte ha "standardsvaret". Jag hade hoppats att någon annan hade uppmärksammat problemet och att detta kunde göras via en dold inställning eller i något skript.

Visa signatur

http://www.theatlantic.com/national/archive/2012/05/how-the-p...
"If there's a simple lesson in all of this, it's that hoaxes tend to thrive in communities which exhibit high levels of trust. But on the Internet, where identities are malleable and uncertain, we all might be well advised to err on the side of skepticism."

Permalänk
Avstängd
Skrivet av Genesis:

Sen, har du inte några fel i din tabell under "Borde vara"?
Ska inte 999 byte bli 999.0 byte om det ALLTID ska vara fyra värdesiffror, trotts att decimaler av byte inte finns?

Nej, fyra värdesiffror där det är relevant förstås. Som sagt, bråkdelars byte finns inte på filnivå.

Skrivet av Genesis:

Och 999999 byte och 999999999 i fyra värdesiffror verkar du ha avrundat fel. Det blir inte 999.9 kB/999.9 MB. Det ska avrundas till 1000 kB/1000 MB alternativt 1.000MB/1.000GB.

Jo, kanske det. Det beror på om man vill trunkera eller avrunda. Frågan är om inte trunkering är bättre eftersom det kanske säger mer om filen. I sådant fall är endast det sista exemplet fel, trunkerat är det 1,073 GB.

Hur menar du att det skulle förvirra med att presentera samma antal värdesiffror? Det som ÄR förvirrande är skillnaden mellan 1000.0 MB och 1 TB. DET är verkligen förvirrande. Från fem till en siffra på en bytes skillnad, det saknar faktiskt logik. Dessutom råkar tre värdesiffror vara tämligen så standard i alla sammanhang med SI-prefix. Jämför med valuta där två decimaler alltid är standard. Ingen kan väl bli förvirrad av konsekvens, eller? Jag har aldrig hört att någon blir förvirrad av detta under Windows, som trots allt gör rätt om jag minns rätt. Jag skulle tro att alla filhanterare i alla tider mestadels varit konsekventa och att Nautilus är ett undantag.

Visa signatur

http://www.theatlantic.com/national/archive/2012/05/how-the-p...
"If there's a simple lesson in all of this, it's that hoaxes tend to thrive in communities which exhibit high levels of trust. But on the Internet, where identities are malleable and uncertain, we all might be well advised to err on the side of skepticism."

Permalänk
Entusiast

Jodå. Jag har också noterat detta. I flertal olika filhanterare också.
Det har resulterat i att jag aldrig använder dessa avrundade siffror till annat än att få en grov uppskattning.
De gånger jag behöver exakta siffror, ser jag till att visa storleken i bytes.

Det är lite underligt att folket bakom dessa filhanterare som är så noggranna med att följa standarder, inte kan få till en logisk och konsekvent decimalvisning/precision.

Skickades från m.sweclockers.com

Visa signatur

Bästa programmen till Linux - v2.0
Linux-guide: Val av grafisk miljö. (Att välja distribution).
-
Everyone should have a SGoC in their systems (SGoC: SysGhost on a Chip)

Permalänk
Medlem
Skrivet av MBY:

Jo, kanske det. Det beror på om man vill trunkera eller avrunda. Frågan är om inte trunkering är bättre eftersom det kanske säger mer om filen.

Fast trunkering är ju matematiskt fel, och då presenteras ju inte korrekta värden. Så att förespråka trunkering fast med korrekt antal värdesiffror känns som en udda blandning. Och jag vet inte om jag håller med dig om att trunkering säger mer om filstorleken än avrundning. I de flesta fall tycker jag avrundning är ett betydligt bättre val. I vissa fall kanske det är bättre precis just kring ett byte av prefix, men varför skulle säg 16947 byte trunkeras till 16.94 kB i stället för att avrundas till 16.95 kB? Jag ser inget bättre med trunkering mot avrundning i de flesta fallen.

Och frågan är ju som sagt vad syftet med Nautilus filstorleksrapportering är. Är det att presentera vetenskapligt och matematiskt korrekta avrundade värden? Eller att med så få siffror som möjligt säga så mycket som möjligt om filstorleken? Eller att göra det så lätt som möjligt för snittanvändaren att så snabbt som möjligt få ut ett grovt värde på hur stor filen är?
Jag tror programmerarna bakom Nautilus lutar åt den senare.

Skrivet av MBY:

Hur menar du att det skulle förvirra med att presentera samma antal värdesiffror? Det som ÄR förvirrande är skillnaden mellan 1000.0 MB och 1 TB. DET är verkligen förvirrande. Från fem till en siffra på en bytes skillnad, det saknar faktiskt logik. Dessutom råkar tre värdesiffror vara tämligen så standard i alla sammanhang med SI-prefix. Jämför med valuta där två decimaler alltid är standard. Ingen kan väl bli förvirrad av konsekvens, eller?

Jag gissar att gemene man inte fullt förstår systemet med värdesiffror, och framför allt inte är van vid det. Och att ha en konstant bredd på kolumnen med filstorlekar, men där decimalpunkten eller decimalkommat varierar position kommer att göra det svårare att snabbt och grovt avläsa filstorleken, främst då de är ovana vid att göra det.
De är inte intresserade av varken en matematiskt eller vetenskapligt korrekt avrundning, eller en så särskilt exakt presentation av filstorleken. Och att då alltid ha decimalpunkten eller decimalkommat på samma position och att variera antalet värdesiffror tror jag är lättare, då det påminner betydligt mer om hur de själva hanterar siffror, och hur de är vana att se siffror från andra.

Men ett sådant system har ju även ett par nackdelar. Filer större eller lika med 1 kB och mindre än 1 MB får prefixet kB, och då 999999 byte är mindre än 1 MB så avrundas det till 1000.0 kB i stället för 1 MB. Vilket ju inte är helt snyggt, och min gissning är att det mest beror på att programmerarna inte orkat lägga till kod för att se om den typen av avrundningar uppåt till där nästa prefix borde användas, snarare än att de tycker att så som det nu är är det optimala beteendet.

12.34 kB 12.3 kB 2.345 MB 2.3 MB 345.6 MB 345.6 MB 456.7 kB 456.7 kB 5.678 MB 5.7 MB 67.89 kB 67.9 kB

Så för att förtydliga så tror jag att gemene man är mer van vid att se siffror arrangeras i stil med min högra kolumn, och är ovan vid att se siffror i stil med min vänstra kolumn. Och jag skulle tro att det tar längre tid för snittanvändaren av Nautilus att leta efter decimalpunkten än att i förväg veta var decimalpunkten finns.
Vad jag personligen stör mig på i så fall är snarare varför 1000 byte avrundas till 1 kB, men att 1100 byte avrundas till 1,1 kB. Jag hade förväntat mig konstant antal decimalvärden, där 1000 byte avrundas till 1.0 kB eller att 1100 byte avrundas till 1 kB beroende på hur många decimalvärden som används.

Sedan kan det ju såklart diskuteras kring om man bör göra det enkelt för folk att fortsätta göra "fel", eller om man ska uppfostra folk och tvinga det att göra "rätt" så att de tillslut lär sig. Men det är nog inte skaparna av Nautilus så intresserade av.
Men de borde egentligen lägga till någon form av inställning för hur man vill ha sina siffror avrundade. För personer som arbetar mycket med avrundningar med korrekt antal värdesiffror så förstår jag helt klart att de stör sig på att felaktiga avrundningar är så vanliga fortfarande.

Permalänk
Hedersmedlem
Skrivet av MBY:

"Standardsvaret" är ju inte mycket till hjälp. Jag föreställde mig att detta hanterades i skript eller i inställningsfiler. Är det hårdkodat i källkoden är det förstås extra dumt och problematiskt. Visst, jag skulle kunna ladda hem källkoden, fixa problemet för mig själv, men det skulle ju inte vara en lösning. Varje uppdatering skulle paja det igen. Jag är inte med i någon community, är inte linux-utvecklare och kan/vill därför inte ladda upp saker "upstream". Ett betydligt vettigare svar hade varit att berätta var eller till vem man rapporterar detta och kanske funderingar på varför ingen reagerat på åratal på detta idiotiska beteende i Nautilus.

Man kan väl alltid klaga här: https://bugzilla.gnome.org

Edit: Någon verkar ha hunnit före (med i alla fall snarlika problem): https://bugzilla.gnome.org/show_bug.cgi?id=94691 . För väldigt länge sedan dessutom...

Permalänk
Medlem

Kolla om nemo eller annan filhanterare är mer konsekvent, eller fixa problemet. Det
finns inte mycket annat att göra.

För övrigt så är trunkering ett oskick, avrundning ska ske med 4/5.
Att alltid använda tre värdesiffror är också ett oskick då det ser ut som om svaret alltid
är exakt till tre värdesiffror. 1.000kB uppfattas som mycket exaktare än 1kB även om det,
rent matematiskt, är samma.

Skrivet av Elgot:

Man kan väl alltid klaga här: https://bugzilla.gnome.org

Man få ungefär samma resultat om man skickar buggrapporten till /dev/null, tyvärr...

Permalänk
Avstängd
Skrivet av Elgot:

Man kan väl alltid klaga här: https://bugzilla.gnome.org

Edit: Någon verkar ha hunnit före (med i alla fall snarlika problem): https://bugzilla.gnome.org/show_bug.cgi?id=94691 . För väldigt länge sedan dessutom...

Intressant! Ja, att alltid använda kB är ju en lösning. Jag har för mig att Windows använder byte och kB. Då behövs inte värdesiffror heller (eller det räcker med färre).

Visa signatur

http://www.theatlantic.com/national/archive/2012/05/how-the-p...
"If there's a simple lesson in all of this, it's that hoaxes tend to thrive in communities which exhibit high levels of trust. But on the Internet, where identities are malleable and uncertain, we all might be well advised to err on the side of skepticism."

Permalänk
Avstängd
Skrivet av Genesis:

Fast trunkering är ju matematiskt fel, och då presenteras ju inte korrekta värden.

Va, nej! Det är inte "matematiskt fel" med någon form av avrundning, floorfunktion eller ceil, 4/5-avrundning, 1/2-avrundning, etc, etc. Det beror helt på sammanhanget och vad som är relevant för applikationen.

Skrivet av Genesis:

Så att förespråka trunkering fast med korrekt antal värdesiffror känns som en udda blandning. Och jag vet inte om jag håller med dig om att trunkering säger mer om filstorleken än avrundning.

Det vore ingalunda en "udda" eller speciellt ovanlig blandning. I många sammanhang kan man rentav utgå från att det handlar om trunkering. Alla miniräknare som inte använder guads digits trunkerar. Flyttalsoperationer trunkerar i regel, eller använder former av avrundning som är rätt komplicerade. Trunkering är troligen vanligare än avrundning. Om man använder avrundning måste man dessutom bestämma sig för vilken metod man ska använda. Ibland används rentav så kallad "stokastisk avrundning", dvs man låter slumpen avgöra.

Så återigen, trunkering är inte "matematisk fel".

Det är inte självklart vilket som är bäst för filstorlekar. Trunkering torde ha sina fördelar, men visst, om du kan finna goda anledningar till avrundning samt vilken form av avrundning (t.ex. halva mot jämt-avrundning) så låt gå för det. Anledningen till att jag vid första påseende tycker att trunkering är bättre är att man vet om en gräns (t.ex. kluster/nod-gräns) har passerats. Dessutom kan man vara säker på att en 15,999 MB stor fil kan flyta i ett 16 MB-minne. Men det är klart, trunkering är därför kanske mer relevant för kibi-prefixen (alltså MiB) än för decimalprefixen.

Summa summarum, det kan finnas skäl för både avrundning (av något slag) och trunkering. Det beror på. Det var heller aldrig andemeningen med mitt inlägg, utan att det är löjligt att en fil presenteras som 1000.0 MB och en annan som 1 GB, från fem siffror till en på en bytes skillnad.

Skrivet av Genesis:

Och frågan är ju som sagt vad syftet med Nautilus filstorleksrapportering är. Är det att presentera vetenskapligt och matematiskt korrekta avrundade värden?

Nej, det är inte nödvändigt även om det knappast är fel. Beror på vad du menar med "vetenskaplig och matematiskt korrekta", det är nämligen inte självklart. S.k. "scientific rounding" är kanske inte avrundning som du tror. 4,35 ska då rundas till 4,3, men 4,5 ska avrundas till 5. Märkligt nog.

Skrivet av Genesis:

Eller att med så få siffror som möjligt säga så mycket som möjligt om filstorleken?

Ja, precis. T.ex. genom att använda lika många siffror varje gång så vi slipper stollerier som 1000.0 MB vs 1 GB.

Skrivet av Genesis:

Eller att göra det så lätt som möjligt för snittanvändaren att så snabbt som möjligt få ut ett grovt värde på hur stor filen är?

Ja, det också. Alltså inte visa en fil som 1000.0 MB och en annan som 1 GB.

Skrivet av Genesis:

Jag tror programmerarna bakom Nautilus lutar åt den senare.

Nja, jag lutar nog att de inte tänkt alls. Alternativt tänkt fel.

Skrivet av Genesis:

Jag gissar att gemene man inte fullt förstår systemet med värdesiffror, och framför allt inte är van vid det. Och att ha en konstant bredd på kolumnen med filstorlekar, men där decimalpunkten eller decimalkommat varierar position kommer att göra det svårare att snabbt och grovt avläsa filstorleken, främst då de är ovana vid att göra det.

Men saker ska inte fördummas med flit. Varför skulle gemene man ha lättare med 1000.0 MB och 1 TB än 1000 MB och 1,000 GB? Man MÅSTE ju ändå titta på prefixet för att veta något om storleken.

Skrivet av Genesis:

De är inte intresserade av varken en matematiskt eller vetenskapligt korrekt avrundning, eller en så särskilt exakt presentation av filstorleken. Och att då alltid ha decimalpunkten eller decimalkommat på samma position och att variera antalet värdesiffror tror jag är lättare, då det påminner betydligt mer om hur de själva hanterar siffror, och hur de är vana att se siffror från andra.

Jag tror helt enkelt att du har fel. Fast jag vill inte ha det här till en trosfråga. Det är lite för mycket "tant Agda"-felslutet här, att göra sig en fördomsfull modell över hur den "vanliga användaren" är. Det finns ingen "vanlig användare", varje användare är unik på ett kontinuum av kompetens från okunnig till kunnig.

Bättre är att göra det vettigt, t.ex. genom att inte visa en fil som 1000,0 MB och en annan som 1 GB. _Det_ är nämligen förvirrande. Varför så exakt i första fallet och så grovt i det andra?

Skrivet av Genesis:

Sedan kan det ju såklart diskuteras kring om man bör göra det enkelt för folk att fortsätta göra "fel", eller om man ska uppfostra folk och tvinga det att göra "rätt" så att de tillslut lär sig. Men det är nog inte skaparna av Nautilus så intresserade av.
Men de borde egentligen lägga till någon form av inställning för hur man vill ha sina siffror avrundade. För personer som arbetar mycket med avrundningar med korrekt antal värdesiffror så förstår jag helt klart att de stör sig på att felaktiga avrundningar är så vanliga fortfarande.

Precis min åsikt. Det borde vara en inställning. Den behöver inte vara lättåtkomlig för att inte förvirra, men det borde finnas i ett inställnings-script.

Men återigen, "avrundning" kan ske på olika sätt. Det är inte mer "korrekt" att avrunda än att trunkera. Det beror helt på sammanhanget. Kanske det bästa vore att alltid visa filstorleken i bytes eller kB och små filer i byte. Man måste inte byta prefix vid varje faktor 1000 (eller 1024).

Visa signatur

http://www.theatlantic.com/national/archive/2012/05/how-the-p...
"If there's a simple lesson in all of this, it's that hoaxes tend to thrive in communities which exhibit high levels of trust. But on the Internet, where identities are malleable and uncertain, we all might be well advised to err on the side of skepticism."

Permalänk
Avstängd
Skrivet av Pie-or-paj:

Kolla om nemo eller annan filhanterare är mer konsekvent, eller fixa problemet. Det
finns inte mycket annat att göra.

För övrigt så är trunkering ett oskick, avrundning ska ske med 4/5.
Att alltid använda tre värdesiffror är också ett oskick då det ser ut som om svaret alltid
är exakt till tre värdesiffror. 1.000kB uppfattas som mycket exaktare än 1kB även om det,
rent matematiskt, är samma.

Nja, du missar totalt att filer faktiskt har en exakt storlek. ALLA filer har en exakt storlek ner till 1 bytes precision. Det finns inga filer som är "ungefärliga". Alltså kan det inte vara frågan om så kallad falsk precision. Dessutom är 4/5-avrundning inte självklar. Jag motsätter mig absolut inte den formen av avrundning, men som jag påpekade i mitt tidigare inlägg finns det en myriad av olika avrundningstekniker (varav trunkering strikt taget är en), där trunkering har sina fördelar. Och nackdelar, givetvis.

Men återigen, min poäng är inte vare sig explicit antal värdesiffror eller avrundning, utan att det är inkonsekvent att visa en fil så precist som 1000,0 MB och en annan som 1 GB. Ingen kan påstå att det är det "enklaste" sättet för "normalanvändaren" (i den mån man kan tala om sådana) eller att det skulle vara korrekt etc. Vad jag ser finns bara argument mot 1000,0 vs 1 GB än för.

Skrivet av Pie-or-paj:

Man få ungefär samma resultat om man skickar buggrapporten till /dev/null, tyvärr...

Jepp, jag är rädd för det!

Visa signatur

http://www.theatlantic.com/national/archive/2012/05/how-the-p...
"If there's a simple lesson in all of this, it's that hoaxes tend to thrive in communities which exhibit high levels of trust. But on the Internet, where identities are malleable and uncertain, we all might be well advised to err on the side of skepticism."

Permalänk
Hedersmedlem
Skrivet av Genesis:

12.34 kB 12.3 kB 2.345 MB 2.3 MB 345.6 MB 345.6 MB 456.7 kB 456.7 kB 5.678 MB 5.7 MB 67.89 kB 67.9 kB

Så för att förtydliga så tror jag att gemene man är mer van vid att se siffror arrangeras i stil med min högra kolumn, och är ovan vid att se siffror i stil med min vänstra kolumn. Och jag skulle tro att det tar längre tid för snittanvändaren av Nautilus att leta efter decimalpunkten än att i förväg veta var decimalpunkten finns.

Jag får nog räknas till icke-gemene man gällande hur många mätvärden jag ser på dagarna, och jag hade föredragit den högra kolumnen här likväl.

En fördel med filer på en dator är att man ju faktiskt har exakta värden som filhanteraren har full koll på (inga halva bitar eller osäkerheter — däremot teknisk skillnad mellan filstorlek och storlek på disk, men det är en annan fråga ). Om man är intresserad av exakta värden på filstorlek så kan man jämföra med vanlig `ls -l`-output, där storleken ges utan prefix i rena bytes. Om man däremot vill titta på värden som förkortas med hjälp av prefix (jfr m `ls -lh`) så är man ju (åtminstone så är min tes detta) intresserad snarare av storleksordningar och någon värdesiffra för rangordning än något exakt — man har redan "gett upp" exaktheten för att tjäna i överblickbarhet, så att säga. Det är inte ofta jag känner att jag är intresserad av att veta om en fil är 238.748 MB eller 238.703 MB stor: men 238.7 MB kan vara intressant information.

Mest överblickbart är på samma sätt din högra kolumn, trots att den må vara inkonsekvent med värdesiffror, men som sagt: är man intresserad av exakta storlekar så har man alltid rena byte-värden att titta på. Även dessa är lätta att visuellt rangordna, åtminstone i högerjusterad fixed-width, men ibland klurigare att visuellt omvandla till exakt storleksordning — snabbt: hur många GB är 213691635 B?

Jag vet inte hur enkelt det är att växla mellan "byte"- och "human readable"-utskrifter, dock, men det hade varit trevligt om det var enkelt.

Skrivet av Pie-or-paj:

För övrigt så är trunkering ett oskick, avrundning ska ske med 4/5.

Ärlig fråga: menar du att avrundning ska ske till närmaste 0.2-kvanta, eller till "4 eller 5 värdesiffror" eller något annat? EDIT: Ah, du menar kanske bara avrundning enligt vanliga (svenska) regler?

Skrivet av Pie-or-paj:

Att alltid använda tre värdesiffror är också ett oskick då det ser ut som om svaret alltid
är exakt till tre värdesiffror. 1.000kB uppfattas som mycket exaktare än 1kB även om det,
rent matematiskt, är samma.

Filstorleken är ju alltid något exakt som är känt här, så jag ser inte problemet med att svara 1.000 kB om det handlar om 1000 B. Om det däremot är 1002 B så skulle man ju då skriva 1.002 kB, men kanske fortfarande 1 kB, då det senare fortfarande inte antyder mer exakthet än till närmsta kB.

Samtidigt så ser man ju att det är utan värde att använda prefixen för att "förenkla" om man ändå tänkt ange exakta värden likt 32.768 kB — man har inte sparat någon plats, utan snarare bara lagt till syntax utan att det förenklar nämnvärt. Tydligare vore då att bara gruppera siffrorna om tre med tunna mellanslag, så att man skriver exempelvis 32 768  B, eller till och med anger den konsekventa enheten byte i kolumnens rubrik och bara anger siffran.

Värdesiffror är i praktiken något som används för att förmedla och hålla koll på osäkerhet i mätvärden. Att filstorlekar är exakta diskreta entiteter gör att vissa omständigheter ändras, i mina ögon. Man kan även tänka sig fall där man är intresserad av ungefärliga filstorlekar rapporterade av filsystemet, men det är åter en sidofråga.

Men ja, det finns många sätt på vilka man kan presentera data . Jag förstår dock tanken bakom Nautilusteamet (om man får förmoda att det finns en sådan) att samma ramverk som för att presentera fysikaliska mätvärden inte måste vara det optimala för "human readable" filstorlekar.

Däremot tycker jag också att Nautilus sett verkar osmidigt, men mitt förslag hade i stället varit:

Filstorlek (byte) Rapporterad storlek phz hade presenterat som 999 999 B 999 B 1000 1 kB 1.0 kB 1023 1 kB 1.0 kB 999999 1000.0 kB 1.0 MB 1000000 1 MB 1.0 MB 999999999 1000.0 MB 1.0 GB 1000000000 1 GB 1.0 GB 1073741824 (1 GiB) 1.1 GB 1.1 GB 32768 32.8 kB 123456 123.5 kB 123456789 123.5 MB 1234567890 1.2 GB

För jämförelse kan vi titta på hur `ls -lh` löser sin omvandling; då under tvångsvillkoret att storleksutskriften bara får ta 4 tecken i anspråk:

$ mkdir test && cd test $ for i in 1000 10000 1000000 1000000000 1023 1024 1025 1048576 1073741824 999 9999 999999 999999999; do truncate -s $i $i; done $ ls -l # Friserad output för forumets skull; storlek till vänster, filnamn till höger total 2932744 999 999 1000 1000 1023 1023 1024 1024 1025 1025 9999 9999 10000 10000 999999 999999 1000000 1000000 1048576 1048576 999999999 999999999 1000000000 1000000000 1073741824 1073741824 $ ls -lh total 2,8G 999 999 1000 1000 1023 1023 1,0K 1024 1,1K 1025 9,8K 9999 9,8K 10000 977K 999999 977K 1000000 1,0M 1048576 954M 999999999 954M 1000000000 1,0G 1073741824

Det är egentligen samma tanke som jag hade ovan, förutom att de skippar decimalen för att hålla sig inom teckengränsen när mätetalet är större än eller lika med 10. De använder även binärräkning för prefixen, vilket jag kanske också egentligen föredrar; att konvertera mitt tidigare exempel till KiB osv lämnas som en uppgift till läsaren .

EDIT: Whoops, där fick man för att man kombinerar OS och SweClockers . En hög med svar innan jag skickade, så det blev nog en del upprepning.

Visa signatur

Nu med kortare användarnamn, men fortfarande bedövande långa inlägg.

Permalänk
Medlem
Skrivet av MBY:

Slutsatsen, nej, jag vill inte ha "standardsvaret". Jag hade hoppats att någon annan hade uppmärksammat problemet och att detta kunde göras via en dold inställning eller i något skript.

Detta kanske inte riktigt är vad du tänkte med skript, men det går att lösa ganska enkelt genom att skriva ett bibliotek (.so fil) som överlagrar beteendet som gör byte->"human readable" konverteringen och sedan ladda in det biblioteket innan "det riktiga" så att ens egen kod körs istället.
Då behöver man dock köra "LD_PRELOAD=biblioteket.so nautilus" för att starta nautilus, så lite obekvämt blir det ju.
Men det blir å andra sidan inte förstört varje gång man updaterar nautilus eller dess bibliotek..

Visa signatur

The difference between stupidity and genius - the latter has limits

Permalänk
Medlem

Jag var påväg att svara något i stil med "Data är inte detsamma som information, så även om du kanske har rätt på datanivå, så har man valt detta för att det bättre förmedlar information om filernas storlek", men sen såg jag att de (enligt OP) gör skillnad på 1000.0MB och 1 GB och gör det konsekvent. Visst, det betyder samma sak, men jag kan knappast säga att endera alternativet är mer informativt...

Permalänk
Avstängd
Skrivet av phz:

Jag får nog räknas till icke-gemene man gällande hur många mätvärden jag ser på dagarna, och jag hade föredragit den högra kolumnen här likväl.

Ja, hens högre kolumn är bra mycket snyggare än idiotin med 1000.0 MB vs 1 GB och får med fler relevanta siffror (värdesiffror) i genomsnitt. Konsekvens ska vara ledordet. Tråden har hakat upp sig lite för mycket på värdesiffror. Var nog dumt av mig att döpa tråden till "Nautilus och värdesiffror". Det är ju konsekvensen som är det viktiga. Det är en stor fördel om man kan ha prefixet och decimaltecknet i samma kolumn statiskt. Nautilus gör ju nästan så, förutom den idiotiska "rollovern" från 1000.0 kB till 1 MB. Och varför bara en decimal? Då hade jag faktiskt hellre levt med flytande komma, men allra helst kunde man helt enkelt ha whitespace för att få snygga kolumner och man skulle spara en massa plats jämför med att skriva ut storleken i bytes.

Visa signatur

http://www.theatlantic.com/national/archive/2012/05/how-the-p...
"If there's a simple lesson in all of this, it's that hoaxes tend to thrive in communities which exhibit high levels of trust. But on the Internet, where identities are malleable and uncertain, we all might be well advised to err on the side of skepticism."

Permalänk
Avstängd
Skrivet av Zevon:

Detta kanske inte riktigt är vad du tänkte med skript, men det går att lösa ganska enkelt genom att skriva ett bibliotek (.so fil) som överlagrar beteendet som gör byte->"human readable" konverteringen och sedan ladda in det biblioteket innan "det riktiga" så att ens egen kod körs istället.
Då behöver man dock köra "LD_PRELOAD=biblioteket.so nautilus" för att starta nautilus, så lite obekvämt blir det ju.
Men det blir å andra sidan inte förstört varje gång man updaterar nautilus eller dess bibliotek..

Tack för ett konstruktivt förslag! Tyvärr låter det som lite för mycket jobb och riskfyllt. Vi vet ju inte hur Nautilus använder biblioteket internt. Man måste nog gräva en del i källkoden för att försäkra sig om att det är ok. Och för att ta reda på vad funktionen heter som ska överlagras förstås. Men förslaget är bra, för samma idioti finns ju i filkopieringsfönster o.dyl och det är väl Nautilus i bakgrunden även där (under Debian/Ubuntu/etc)?

Visa signatur

http://www.theatlantic.com/national/archive/2012/05/how-the-p...
"If there's a simple lesson in all of this, it's that hoaxes tend to thrive in communities which exhibit high levels of trust. But on the Internet, where identities are malleable and uncertain, we all might be well advised to err on the side of skepticism."

Permalänk
Avstängd
Skrivet av phz:

Mest överblickbart är på samma sätt din högra kolumn, trots att den må vara inkonsekvent med värdesiffror, men som sagt: är man intresserad av exakta storlekar så har man alltid rena byte-värden att titta på. Även dessa är lätta att visuellt rangordna, åtminstone i högerjusterad fixed-width, men ibland klurigare att visuellt omvandla till exakt storleksordning — snabbt: hur många GB är 213691635 B?

Precis. Tipset "titta på propertys om du vill ha exakt" är ju inte så hjälpfullt av just den anledningen. Här råkar det ju vara så i Nautilus att det faktiskt blir tusentals-separerat vilket är jättebra (till skillnad från Windows XP-), förutom när man ska kopiera filstorleken. Men kolumnerna hade blivit fasligt breda om man skulle presentera i bytes och dessutom tusentalsgruppera (vilket vore ett måste).

Visa signatur

http://www.theatlantic.com/national/archive/2012/05/how-the-p...
"If there's a simple lesson in all of this, it's that hoaxes tend to thrive in communities which exhibit high levels of trust. But on the Internet, where identities are malleable and uncertain, we all might be well advised to err on the side of skepticism."

Permalänk
Medlem
Skrivet av MBY:

Tack för ett konstruktivt förslag! Tyvärr låter det som lite för mycket jobb och riskfyllt. Vi vet ju inte hur Nautilus använder biblioteket internt. Man måste nog gräva en del i källkoden för att försäkra sig om att det är ok. Och för att ta reda på vad funktionen heter som ska överlagras förstås. Men förslaget är bra, för samma idioti finns ju i filkopieringsfönster o.dyl och det är väl Nautilus i bakgrunden även där (under Debian/Ubuntu/etc)?

Funktionen som sköter storlek->text heter g_format_size och kommer från biblioteket glib, den anropar i sin tur funktionen g_format_size_full (som stödjer flaggor, såsom om det ska rapporteras i basen 1000 eller 1024, eller om det ska visas som bytes eller med suffix).
En snabbsökning visar att nautilus använder g_format_size förutom där den behöver den den exakta storleket (i "file properties" fönstret ex) då den anropar g_format_size_full med "visa som bytes" flaggan.
För vårt syfte så fungerar det alltså helt utmärkt att enbart överlagra g_format_size varianten eftersom "som bytes" varianten redan gör precis vad den borde göra.

Exempellösning:
Den här varianten skriver ut allt under 1000bytes som bytes (ex. "10 B") och allt över detta som kilobyte med en decimal (ex. "10.0 kB"). Ingen tusentalsgruppering så kanske inte helt användbart, men fungerar som proof-of-concept iaf, och den är ju lätt att utöka till sina behov.

Källkodsfilen filesize.c

#include <glib.h> gchar * g_format_size(guint64 size) { GString *string; string = g_string_new (NULL); if(size<1e3) { g_string_printf(string, "%u B", (guint)size); } else { g_string_printf(string, "%.1f kB",(gdouble)size/(gdouble)1000.0); } return g_string_free (string, FALSE); }

Kompilera till biblioteket libfilesize.so:

gcc `pkg-config --cflags --libs glib-2.0` -Wall -std=c99 -shared -Wl,-soname,libfilesize.so.1 -fPIC -o libfilesize.so filesize.c

Använd som:

LD_PRELOAD=./libfilesize.so nautilus

Den riktiga implementationen av g_format_size finns i glib/gutils.c, som kan ses online på:
https://git.gnome.org/browse/glib/plain/glib/gutils.c

Visa signatur

The difference between stupidity and genius - the latter has limits

Permalänk
Avstängd

Superbt svar, Zevon!

Du målar nästan in mig i ett hörn, jag har inga ursäkter längre att _inte_ pilla lite källkod med detta.

Visa signatur

http://www.theatlantic.com/national/archive/2012/05/how-the-p...
"If there's a simple lesson in all of this, it's that hoaxes tend to thrive in communities which exhibit high levels of trust. But on the Internet, where identities are malleable and uncertain, we all might be well advised to err on the side of skepticism."

Permalänk
Medlem

asså vilket problem skulle det inte bara vara lättare att använt terminalens "ls -l"?:S

Visa signatur

Смерть -это решение всех проблем. Нет человека - нет проблемы
Comp1: Ubuntu 16.04 Comp2: Arch Linux
Comp3: Ubuntu Server 16.04 Comp4: Centos 6.5
Comp5: Linux mint 16 Comp6: Raspberry pi (olika OS hela tiden)
Phone: Motorola Google Nexus 6

Permalänk
Avstängd
Skrivet av Mejan:

asså vilket problem skulle det inte bara vara lättare att använt terminalens "ls -l"?:S

Givetvis förstår du skillnaderna i fördelar och nackdelarna med att arbeta i CLI jämfört med fördelarna och nackdelarna med att arbeta i GUI?

Naturligtvis finns det flera sätt att ta reda på filstorlekar, exakt och ungefärligt. Jag arbetar mycket i terminalfönstret, men det är inte samma sak. Överblicken är en annan i GUI och CLI och GUI kompletterar varandra. Det är opraktiskt att köra ls -l varje gång man vill ha överblick när man sitter i Nautilus. Det är ju inte så att jag inte vet vad jag ska göra för att veta storleken på en fil...

Visa signatur

http://www.theatlantic.com/national/archive/2012/05/how-the-p...
"If there's a simple lesson in all of this, it's that hoaxes tend to thrive in communities which exhibit high levels of trust. But on the Internet, where identities are malleable and uncertain, we all might be well advised to err on the side of skepticism."

Permalänk
Avstängd

Det här blir en bump då jag fortfarande inte fått någon lösning på detta problem som går mig på nerverna. Nu har jag sedan en tid tillbaka migrerat till Mate och dess filhanterare Caja som är precis samma sak som Nautilus i princip. Skillnaden är ju som alla känner till att Gnome-gänget bestämde sig för att förstöra allt gott, så det blev en fork.

Nåväl, bekymret är naturligtvis det samma i Caja som i Nautilus. Filstorlekar rapporteras på samma idiotiska manér. Googlingar kammar noll och ibland hittar man github som listar någon jävla källkod i C eller python eller liknande, helt utan några som helst referenser till vad det är och vad göra med det. Caja ska stödja plugins eller extensions (olika termer på olika ställen, finfint) men det verkar inte finnas några sådana, verkar inte visas några sådana och ingen verkar veta hur man utvecklar eller installerar sådana. Det enda som verkar finnas är något för att öppna en terminal i aktuell katalog, något som jag tydligen redan har i Caja som fungerar fint men inte listas någonstans ö.h.t (properties->plugin visar inget).

Bara en bit kod i valfritt språk säger givetvis ingenting. Är det en del av caja? Ska jag kompilera om caja? Ska jag lägga ett skript i en speciell katalog? Etc, etc.

Hur ett fält ska formateras är så jättefundamentalt självklart att kunna konfigurera så jag förstår inte varför det inte finns någon .conf-fil eller liknande för att ändra detta. Saken verkar hårdkodad och ingen annan i universum verkar uppmärksammat detta fundamentala och simpla problem (testa att googla på "caja size column significant digits" eller liknande. Bara skitträffar, ingenting relevant).

Om jag lyckas omformulera Zevons svar så att det gäller caja (vilket jag inte har en susning om), så kanske jag kan fixa detta själv, men det känns som allting kommer bli förstört vid första bästa apt-get update eller paja något annat. Samtidigt tycker jag detta är så jäkla banalt självklart så in i bäng, att jag inte har någon lust att ägna minuter, timmar, etc, åt detta.

Är det bara jag som tycker det är fullständigt groteskt att det antingen inte är fler (typ sex siffror) by default eller att man inte bara kan högerklicka på kolumnen och välja antal siffror och prefixbas?

Edit: Btw, jag gjorde en disksökning på "filesize.c". Noll träffar (jag hade förväntat mig multipla träffar och problem med att veta vilken som är relevant). Vet inte riktigt hur jag ska gå vidare. Har installerat "libcaja-extensions-dev", det enda som luktar källkod, från synaptic samt "caja" från github - totalt utan att version o.dyl nämns någonstans någonsin.

Visa signatur

http://www.theatlantic.com/national/archive/2012/05/how-the-p...
"If there's a simple lesson in all of this, it's that hoaxes tend to thrive in communities which exhibit high levels of trust. But on the Internet, where identities are malleable and uncertain, we all might be well advised to err on the side of skepticism."

Permalänk
Hedersmedlem
Skrivet av MBY:

Om jag lyckas omformulera Zevons svar så att det gäller caja (vilket jag inte har en susning om), så kanske jag kan fixa detta själv, men det känns som allting kommer bli förstört vid första bästa apt-get update eller paja något annat. Samtidigt tycker jag detta är så jäkla banalt självklart så in i bäng, att jag inte har någon lust att ägna minuter, timmar, etc, åt detta.

Nu har jag inte möjlighet att testa caja själv för tillfället, men av koden verkar det väl som att även de använder g_format_size till snarlika saker? Vad händer om man försöker med samma trick igen? Apt-get bör inte pilla på ld_preload (utan att varna i alla fall).

Permalänk
Avstängd
Skrivet av Elgot:

Nu har jag inte möjlighet att testa caja själv för tillfället, men av koden verkar det väl som att även de använder g_format_size till snarlika saker? Vad händer om man försöker med samma trick igen? Apt-get bör inte pilla på ld_preload (utan att varna i alla fall).

Ärligt talat så gav jag nog upp förra gången. Kan iaf inte minnas att jag inte stört mig på detta vid något tillfälle. Hade jag grejat det då hade jag antagligen kunnat fixa det även för Caja. Men nu har problemet återaktualiserats när jag råkar ha fem filer som alla är "1.1 GB" stora och jag vill veta vilken som är störst UTAN att sortera om kolumnerna. Alternativet är att högerklicka på varje fil och typ försöka memorera, skriva upp, kopiera, etc, filstorlekarna. Idiotiskt arbetsflöde på grund av att idiotiska utvecklare inte har "attention to detail" eller fixa idéer om användning.

Bekymret är att även om jag är/har varit programmerare så har jag svårt att få överblick över vad som är vad och vilken kod som ligger i vilken fil och används av vad. Jag vet inte ens var jag ska hitta rätt kod och det verkar inte finnas någon central koll/guide på hur man går tillväga för att fixa någon "generisk" linuxdetalj. Kort sagt: jag vet inte om det är Caja som ska fixad, kernel, glibc, Mate, eller något annat. Jag hittade (tror jag) koden till caja på github, dock utan någon specifikation om version o.dyl.

Saker verkar så förbaskat integrerade. Ett annat exempel är en idiotisk detalj i gEdit/pluma - man kan inte öppna godtycklig fil utan att den bråkar om "cannot detect character encoding". Fine, tänkte jag första gången, jag laddar väl ner en annan editor. Nope, no cigar. Alla editorer beter sig på samma sätt och verkar bygga på samma komponenter. "TEA Text Editor" är den enda jag hittat som verkar ge blanka fan i sådant som editorer ska ge blanka fan i och visa tecknen byte-för-byte. Jag tänkte, naivt, att detta borde väl vara snorenkelt att fixa, bara disabla/hoppa över idiotisk kod som "förutsäger character encoding". Men har ingen susning om var den koden finns (framförallt inte varför den finns - en byte = ett tecken. Vill man ha UTF8/16/whatever så får man väl manuellt ange detta. Eller låt mig åtminstone få ange ett tecken = en byte manuellt då, men icke). Jag har någon annan gammal tråd där jag bråkar om varför inga editorer kan använda CP437 längre och rendera tecken för samtliga bytes 0x00 till 0xFF utan måste leva med ^-escapekoder som totalt förstör läsbarheten. T.o.m. hexeditorer visar blankt för majoriteten av alla tecken vilket gör "okulär besiktning" av filer hopplös. Vissa programmerare tycks förutsätta att ingen kan vilja använda program på något som helst annorlunda sätt än de själva (och hexeditorer är ofta read only i antingen hex-fältet eller ASCII-fältet)...

Kort sagt: vet inte var jag ska börja. Men om jag visste vilket område i vilken källfil och var den ligger eller ska ligga, så borde saken vara biff. C/python/pascal/basic/assembler/whatever. Det är samma skit alltihop. Datorer är skit. Det var definitivt bättre förr! /Rant

Visa signatur

http://www.theatlantic.com/national/archive/2012/05/how-the-p...
"If there's a simple lesson in all of this, it's that hoaxes tend to thrive in communities which exhibit high levels of trust. But on the Internet, where identities are malleable and uncertain, we all might be well advised to err on the side of skepticism."

Permalänk
Hedersmedlem
Skrivet av MBY:

Bekymret är att även om jag är/har varit programmerare så har jag svårt att få överblick över vad som är vad och vilken kod som ligger i vilken fil och används av vad. Jag vet inte ens var jag ska hitta rätt kod och det verkar inte finnas någon central koll/guide på hur man går tillväga för att fixa någon "generisk" linuxdetalj. Kort sagt: jag vet inte om det är Caja som ska fixad, kernel, glibc, Mate, eller något annat. Jag hittade (tror jag) koden till caja på github, dock utan någon specifikation om version o.dyl.

Saker verkar så förbaskat integrerade.

Ja, att få överblick över okända (och med lite otur undermåligt dokumenterade) projekt är ju alltid besvärligt, men i just det här fallet har ju Zevon redan gjort jobbet och identifierat vilken funktion som orsaker just detta besvär. Jag antar att anropet för att formatera storlekskolumnen sker på rad ~2415 här:
https://github.com/mate-desktop/caja/blob/master/src/file-man...
men om man inte vill kompilera och manuellt installera caja känns ld_preload-lösningen smidigare. Förmodligen kan ju samma .so-fil användas för att fixa till även andra glib-program med samma problem (och så länge de inte överger glib (eller glib förändras på inkompatibelt vis) bör uppgraderinga och liknande inte orsaka problem).

Permalänk
Medlem
Skrivet av MBY:

Edit: Btw, jag gjorde en disksökning på "filesize.c". Noll träffar (jag hade förväntat mig multipla träffar och problem med att veta vilken som är relevant). Vet inte riktigt hur jag ska gå vidare. Har installerat "libcaja-extensions-dev", det enda som luktar källkod, från synaptic samt "caja" från github - totalt utan att version o.dyl nämns någonstans någonsin.

filesize.c var bara vad jag kallade min kodsnutt så att jag kunde ge ett fullständig kompileringskommando, själva filen med orginalkoden för hur filstorlekarna formateras är gutils.c från glib som länkades i slutet av inlägget.
(https://git.gnome.org/browse/glib/plain/glib/gutils.c)

Citat:

Om jag lyckas omformulera Zevons svar så att det gäller caja (vilket jag inte har en susning om), så kanske jag kan fixa detta själv, men det känns som allting kommer bli förstört vid första bästa apt-get update eller paja något annat. Samtidigt tycker jag detta är så jäkla banalt självklart så in i bäng, att jag inte har någon lust att ägna minuter, timmar, etc, åt detta.

Du behöver inte omformulera något, det fungerar rakt av. (vilket ju är som förväntat iom att Caja och Nautilus i grunden är samma kod).
Skapa filen filesize.c, kopiera in kodsnutten, kör gcc-kommandot och starta sen bara Caja med:

LD_PRELOAD=./libfilesize.so caja

biblioteket som kompileras länkas fö. inte mot några konstiga bibliotek/bilblioteksversioner, så det ska till en ganska rejäl system-uppgradering för att biblioteket inte längre ska fungera.
Och om det skulle sluta fungera så skulle du iaf bara behöva köra om gcc-kommandot för att kompilera upp en ny version.

Visa signatur

The difference between stupidity and genius - the latter has limits

Permalänk
Avstängd

Det låter väldigt, väldigt lovande!

Förstår jag det rätt som att det enda jag egentligen behöver göra är ett litet fristående program i form av ett bibliotek (.so) och med hjälp av LD_PRELOAD knyta det till Caja? Och det programmet kompilerar jag enkelt med gcc utan att behöva ha med miljoner h-filer och dependencies?

Din kompileringsrad
gcc `pkg-config --cflags --libs glib-2.0` -Wall -std=c99 -shared -Wl,-soname,libfilesize.so.1 -fPIC -o libfilesize.so filesize.c
...verkar ju antyda att så är fallet! Detta kanske är enklare än vad jag trodde.

Edit: Testade och din exempelkod kompilerade fint och raden "LD_PRELOAD=./libfilesize.so caja" fungerade utan att klaga i terminalen, men, jag ser ingen skillnad i filstorleken! > 1 GB visas fortfarande som t.ex. 1.1 GB.

Använder caja denna funktion verkligen? Den returnerar ju värdet eller värdet / 1000, men hur vet den kallande funktionen vilket prefix den ska använda? Edit: Korkade mig, det är ju en sträng som returneras och prefixet är ju inskrivet i strängen. Nåja, det verkar inte fungera hursom. Jag har lagt till en "vittnestext" i strängen.

Visa signatur

http://www.theatlantic.com/national/archive/2012/05/how-the-p...
"If there's a simple lesson in all of this, it's that hoaxes tend to thrive in communities which exhibit high levels of trust. But on the Internet, where identities are malleable and uncertain, we all might be well advised to err on the side of skepticism."

Permalänk
Hedersmedlem
Skrivet av MBY:

Det låter väldigt, väldigt lovande!

Förstår jag det rätt som att det enda jag egentligen behöver göra är ett litet fristående program i form av ett bibliotek (.so) och med hjälp av LD_PRELOAD knyta det till Caja? Och det programmet kompilerar jag enkelt med gcc utan att behöva ha med miljoner h-filer och dependencies?

Din kompileringsrad
gcc `pkg-config --cflags --libs glib-2.0` -Wall -std=c99 -shared -Wl,-soname,libfilesize.so.1 -fPIC -o libfilesize.so filesize.c
...verkar ju antyda att så är fallet! Detta kanske är enklare än vad jag trodde.

Precis. Nautilus (och caja) anropar den där funktionen för att omvandla filstorleken till en textsträng och hittar implementationen i något glib-bibliotek. Med hjälp av ld_preload kan man se till att en annan implementation (i det här fallet den i filesize.c) hamnar först i kön av bibliotek att söka igenom och därmed ersätter originalfunktionen.

Några h-filer och bibliotek kommer du nog behöva (glib till exempel), men inget från caja eller liknande.

Permalänk
Avstängd
Skrivet av Elgot:

Precis. Nautilus (och caja) anropar den där funktionen för att omvandla filstorleken till en textsträng och hittar implementationen i något glib-bibliotek. Med hjälp av ld_preload kan man se till att en annan implementation (i det här fallet den i filesize.c) hamnar först i kön av bibliotek att söka igenom och därmed ersätter originalfunktionen.

Hmm. Något fungerar inte (se min edit i föregående inlägg). Och jag förstår inte hur det skulle kunna fungera egentligen då funktionen inte verkar returnera prefixet. Jag testade att ändra printf-strängen och sätta in ett litet vittnesvärde i form av "urk", men inga "urk" syns och filstorleken visas på det gamla viset...

Edit:
Är det säkert att funktionen heter g_format_size, returnerar gchar* och tar en guint64?

Givetvis behöver funktionen inte returnera prefixet separat, den returnerar ju en sträng. Dumma mig. Men, det verkar inte fungera.

Edit2: En annan fråga som naturligt uppkommer, hur får jag caja att automatiskt starta på detta sätt? I Mate-panelen finns ju "Places" där caja öppnas med home eller liknande. Påverkas det beteendet om jag ändrar startraden i "Applications"-menyn?

Visa signatur

http://www.theatlantic.com/national/archive/2012/05/how-the-p...
"If there's a simple lesson in all of this, it's that hoaxes tend to thrive in communities which exhibit high levels of trust. But on the Internet, where identities are malleable and uncertain, we all might be well advised to err on the side of skepticism."