Hvorfor 'readme.txt' istedet for 'readme'?
Det er kjent at historie og vane veier tungt når det gjelder hvordan vi bruker PC’en. Jeg mener at dette er grunnen til at utviklingen går i sneglefart når det gjelder vårt grensesnitt til PC’er. Hender det du setter deg ned og tenker på filnavn? Hvorfor de er som de er og hvilke begrensninger som er knyttet til de? Neppe, med mindre din interesse til datamaskiner grenser til det syke. Undertegnede har altså tenkt mye på filnavn i dag.
For eksempel: README.TXT
En fil heter “README.TXT”. Dette er jo litt forvirrende - navnet på filen burde jo vært “README”. Slutten på filnavnet angir hvilken type fil dette er. “.TXT” forteller oss at dette er en tekstfil. Men vi kaller altså hele navnet (“README.TXT) for filnavnet. Er ikke det rart?
Problemet mitt er altså at når vi sier “filnavn”, så blander vi sammen filnavnet og filtypen.
Warum?
Grunnen til dette er historisk. I gamledager så ble filtype angitt på denne måten. Filnavnet var maks 5-9 bokstaver langt, og filtypen ble angitt av 2-3 bokstaver. Filtypen anga hvilken type fil dette var. Når brukeren skulle taste inn kombinasjonen filnavn + filtype, var det vanlig å skille de med et punktum. Tidlige versjoner av FAT-filsystemet (for de som husker DOS) bygget på denne tanken. Kjørbare filer måtte for eksempel slutte på “.EXE” eller “.COM”. Det kalles “8.3 filename” på godt norsk.
Dette er godt innarbeidet hos de fleste av oss, og (nesten) ingen tenker på det i dag. Jeg har erfart at hos enkelte er det så innarbeidet at de går i forsvarsposisjon hvis jeg påstår at det er en dustete måte å navngi filer på.
Dårlig design.
De historiske grunnene til dette er altså klare. Men hva er grunnen til at vi fortsatt har det i dag? Moderne filsystem støtter metadata som angir en rekke egenskaper ved filene. De forteller oss hvem som eier filen, om den er eksekverbar, når den var opprettet, sist lest, og så videre.
Det er også blitt såpass mange filer at det blir konflikter. Får du en DOC-fil, kan det være ren tekst, eller Microsoft Word-dokument. Får du en IMG-fil, kan det være et CD-image, en fotografi, bitmap bilde, eller et disk-image.
Det er tyvetydelighet rundt hvordan programmer viser filtyper. Du kan motta en epost med en “readme.txt” som du dobbeltklikker på. Det viser seg at filen egentlig het “readme.txt.exe”, og at din PC nå reklamerer stort for viagra eller billige armbåndsur.
Jeg har ikke lyst til å bruke mye tid i dag på å rakke ned på Windows (men det er vanskelig å stanse når jeg først begynner) - jeg har brukt GNU/Linux og BSD for lenge til å være helt oppdatert på Windows.
Altså, jeg mener at der i gården må filtypen være en del av filnavnet. Et program må altså ha et navn som: “program.exe” for å kunne kjøres. NTFS er designet for å kunne lagre en rekke metadata om filene, men Windows baserer seg på at filnavnet må slutte på “.XYZ” for å vite om den skal kjøres eller ikke. Hvorfor da ikke også lagre filtypen som metadata og bruke filnavnet til - tja - filnavnet? Helt idiotisk spør du meg.
Til Windows sitt forsvar, så er det vanlig at GUI på for eksempel GNU/Linux også baserer seg i stor grad på filendelser. Men GNU/Linux i seg selv bryr seg ikke et døyt om hva filen heter.
Andre begrensninger
Et annet tegn på det jeg mener er svakt design på Windows er reserverte filnavn. Du trodde kanskje et filnavn bestod av tekst og kunne være hva som helst (med unntak av noen spesialtegn)?
Windows har også en rekke reserverte ord som hindrer deg fra å lage filer med enkelte navn (du får det til hvis du prøver hardt nok, men det er ikke anbefalt). Du får ikke lage filer av navn som: CON, PRN, AUX, NUL, COM1 til COM9 og LPT1 til LPT9. Også her er grunnen for det meste historisk fra DOS sine dager, selv om “copy con filnavn.txt” eller “copy filnavn.txt prn” også (vistnok) skal virke i dag. Ønsker du å lagre medlemslisten til Namsos Ungdomslag i filen “nul.txt”, eller passord til dine porn voksen-nettsider i filen prn.txt, bør du altså bruke et ordentlig operativsystem. Dette har også ført til en rekke morsomme feil der du kunne provosere frem kræsj ved å referere til filer som “c:\con\con” på forskjellige måter (i HTML-dokumenter eller fra en FTP-klient).
Noe annet merkelig er at NTFS tillater filnavn som slutter på mellomrom eller punktum, men Windows vil ikke tillate dette.
. . Og jeg skal ikke engang begynne å skrive om at Windows ikke ser forskjell på STORE og små bokstaver.
Mitt poeng er at dette er dårlig design, men at det er vanskelig å endre det som brukerne har vendt seg til.
Bedre løsning?
Jeg forstår at folk har sine vaner, og at endring i brukergrensesnitt er noe mange brukere ikke nødvendigvis vil like. Det er kjekt å se ut fra endelsen hvilken type fil det er snakk om, men jeg mener heller at operativsystemer skal designes for å vise filtypen som en egen kolonne i utforskeren, ved ikoner, eller på andre måter. Det er ikke lett å erstatte vanlige teknologier (se på DAB-radioer eller IPv6), og det kan være en leng og smertefull prosess for brukere som har sine faste vaner.
Men er vi ikke snart klare for å legge bak oss begrensninger som stammer fra 60- og 70-tallets operativsystemer? På 70-tallet hadde filendelser en funksjon - i dag er bakoverkompatibilitet hovedårsaken. På Internet bruker vi allerede MIME-typer, og filsystemer lagrer en rekke metadata om filer. Jeg mener informasjonen om filtype er metadata og bør flyttes sammen med resten av metadataene. Filnavn bør brukes til - nettopp - filnavn.
1 TrackBacks
Listed below are links to blogs that reference this entry: Hvorfor 'readme.txt' istedet for 'readme'?.
TrackBack URL for this entry: http://www.int9.net/mt/mt-tb.cgi/38
Int9.net skriv om filnamn, og filetternamn. Han stiller konkret spørsmål om kvifor ein nyttar seg av filetternavn: En fil heter “README.TXT”. Dette er jo litt forvirrende - navnet på filen burde jo vært “README”. Slutten på filnavnet angi... Read More
Mac bruker ikke filendelser. Mac assosierer et program med filene, samt at dersom du lager en JPEG i Photoshop, blir JPEG-filen assosiert med Photoshop, og ikke Preview (forhåndsvisningsprogrammet på Mac). Det fungerer utmerket!
jeg sysnes at æøå bør vises riktig før en begynner å snakke om filendelser.
Server sender ISO-8859-1 og siden er formatert som: utf-8, ser grisat ut
Når en utaler ser om historie bør en også ha "litt" kjennskap til den, PC'en som er ansvarlig for denne typen filnavn eksisterte ikke på 60 og 70 tallet, men kom først i august 1981:
http://nn.wikipedia.org/wiki/Personleg_datamaskin
Anonymous:
Sånn kan det brått gå nå man tuller for mye med konfigurasjonen. Apache sine innstillinger er enkle, men jeg mistenker Movable Type for å tulle til litt når den bygger sider.
Uansett, det er ikke PC'en som er "synderen", men det er mest fordi begrepet PC ikke eksisterte før på 80-tallet.
Hvis du påstår at det er MS-DOS som har innført dette i 1981 så er jeg ikke enig. DOS bygger på CP/M som igjen har lånt denne konvensjonen fra DEC sine tidlige OS - deriblandt TOPS-10 fra 1964.
Så, "litt" historie kan jeg.
Karaktersett kan fixes ved å eks å legge konfigurasjon i .htaccess:
http://www.askapache.com/htaccess/setting-charset-in-htaccess.html
http://httpd.apache.org/docs/1.3/mod/mod_mime.html
http://www.w3.org/International/questions/qa-htaccess-charset
...
Ronny-André Bendiksen:
Mac lagrer istedet faktisk to filer, noe jeg mener er skikkelig idiotisk. Når jeg mottar en fil fra en Macbruker på e-post så får jeg to vedlegg - den ene er en beskrivelsesfil og den andre er selve filen.
Til bloggeren:
Så lenge viktige funksjoner som f.eks. FTP ikke støtter mimetyper så må man ty til filetternavn for å overføre filtype mellom systemer.
Alternativet er selvsagt å legge inn metadata i selve filen slik at operativsystemet kan lese på hver fil for å se typen - men det innebærer at datamaskinen må åpne og lukke alle filene i en katalog for å se filtype og DET er tregt; en moderne datamaskin kan ikke åpne/lukke mer enn ca 150 filer per sekund (avhengig av harddiskens søketid samt om man har SATA/150, SATA/300 osv selvsagt).
Når det gjelder DOS så var de tre bytene som var satt av til filetternavn faktisk den metadataen som fortalte om filtypen og ikke en del av filnavnet. At systemene velger å presentere dette ved å sette sammen filnavn og filtype er en følge av at man kan ha både readme.doc og readme.txt i samme mappe og da må man kunne unikt identifisere rett filtype (f.eks. når man kommuniserer med andre per telefon eller skal starte et program fra kommandolinjen med filnavnet som parameter). Kunne selvsagt skrevet winword document /type=doc men det blir litt vel tungvindt blir det ikke?
Sistnevnte eksempel er vel mer relevant når man har bildefiler (f.eks psd - original photoshop og jpeg) der det ofte er fornuftig å bruke samme filnavn.
Ronny-André Bendiksen:
Mac lagrer istedet faktisk to filer, noe jeg mener er skikkelig idiotisk. Når jeg mottar en fil fra en Macbruker på e-post så får jeg to vedlegg - den ene er en beskrivelsesfil og den andre er selve filen.
Til bloggeren:
Så lenge viktige funksjoner som f.eks. FTP ikke støtter mimetyper så må man ty til filetternavn for å overføre filtype mellom systemer.
Alternativet er selvsagt å legge inn metadata i selve filen slik at operativsystemet kan lese på hver fil for å se typen - men det innebærer at datamaskinen må åpne og lukke alle filene i en katalog for å se filtype og DET er tregt; en moderne datamaskin kan ikke åpne/lukke mer enn ca 150 filer per sekund (avhengig av harddiskens søketid samt om man har SATA/150, SATA/300 osv selvsagt).
Når det gjelder DOS så var de tre bytene som var satt av til filetternavn faktisk den metadataen som fortalte om filtypen og ikke en del av filnavnet. At systemene velger å presentere dette ved å sette sammen filnavn og filtype er en følge av at man kan ha både readme.doc og readme.txt i samme mappe og da må man kunne unikt identifisere rett filtype (f.eks. når man kommuniserer med andre per telefon eller skal starte et program fra kommandolinjen med filnavnet som parameter). Kunne selvsagt skrevet winword document /type=doc men det blir litt vel tungvindt blir det ikke?
Sistnevnte eksempel er vel mer relevant når man har bildefiler (f.eks psd - original photoshop og jpeg) der det ofte er fornuftig å bruke samme filnavn.
Hei,
jojo, Windows bruker filnavn - både for- og etternavn... Get a mac.. der spiller det ikke så stor rolle da den leser headeren på filen :-D og du har rett, det ER dårlig design:-D
/j-man
Har du egentlig argumentert for hva som er dårlig ved designet? Ser bare en påstand egentlig. "Filetternavnet" for å bruke det uttrykket er aldeles utmerket til formålet, nemlig å identifisere filtype. Hva er egentlig galt med det?
Er jo bare å huke av for "Skjul filetternavn for kjente filtyper da". Er default i windows. Personlig liker jeg filetternavnet, for det sier mye med en gang. I eksempelet readme.txt, vet jeg at dette er en simpel tekstfil som kan åpnes i hva som helst, men dersom den egentlig het readme.doc, og jeg ikke hadde word eller noe annet tilsvarende installert ville jeg ikke få gjort noe med denne. Istedet måtte jeg da gått inn i egenskapene til fila for å sjekke hvorfor jeg ikke fikk åpnet den i notepad? Nei. Systemet funker faktisk fint som det er. Og liker man det ikke, så er det bare å skjule.
Det største problemet er vel at ikke alle filsystemene som er i bruk støtter metadata på den måten.
I så fall så bør kanskje diskusjonen være: Er vi ikke snart i stand til å kvitte oss med alle gamle ting?
Hvor skal f.eks. mime-typen lagres hvis du:
- sender en fil på epost (alle epost-programmer må oppdateres til å sende med dette, og da har jeg et bedre ønske: fiks epost så spam er umulig)
- putter en fil i en zip-fil (dvs. alle komprimerings-formater må endres)
- er nødt til å snakke med et system som ikke har støtte for det (ewups, omtrent alle windows-kompatible minnepenner og kameraer i dag bruker Fat(32), metadata? hva er det?)
- sender fil via filoverføring som ikke har en protokoll som inkluderer mime-typer (ftp, IM)?
Jeg skjønner hva han sier, men det blir litt som å tro på julenissen.
Hvis vi først skal diskutere dinosaur-teknologi som burde byttes ut, her er min korte off-the-top-of-my-head liste:
- epost som teknologien er i dag, lag et nytt system som gjør spam umulig
- all bakoverkompatibilitet i HTML
On top of my head - NTFS, FAT32, FAT16, ext2, ext3, ReiserFS, ZFS, HFS+, JFS, etc etc etc.
Det finnes ØRTEN filsystemer der ute som er i aktiv bruk, alle med (vidt) forskjellige måter å lagre metadata (som eierskap, tilgangsrettigheter, attributter, ikon, label etc) som allerede er svært vanskelig å portere lossless og konsekvent. Hvordan skal du håndtere filtypene-metadata i filoverføringsprotokoller som FTP? Enn i arkivering som ZIP og TAR?
Jeg får stadig e-post med vedlegg fra Mac-brukere på hvor jeg gjerne får TO filer per vedlegg hvor begge har samme navn der den ene er resource-forken som er ubrukelig på et ikke-Mac-system. Indikerer ikke filnavnet filtypen må du gjerne ty til en hex-editor og prøve å gjenkjenne formatet ved hjelp av de første 4-5 bytes'ene i fila - kjempemoro ...
Unix-verdens "løsning" på dette med file(8) og en stadig-voksende "magic"-fil med data som lar en gjøre en _gjetning_ på format utifra de første X bytesene er et HORRIBELT hack og om mulig en enda dårligere idé enn å flytte filtype-infoen til filsystemets metadata-lager.
Filtype er by far det viktigste stykke metadata om ei fil, foruten filnavnet selv - noe som i seg selv fordrer særbehandling.
8.3-begrensninga hører fortida til og er ikke noe vi trenger å bry oss om i dag; det er ingen grunn til å i dag begrense seg til en 3-tegns filending for et nytt filformat - med flere tegn unngår man tvetydighetene 8.3 kan føre til (noe som i seg selv er sjeldent og ei søk problemstilling - i de aller, aller fleste tilfeller vil konteksten gjøre det klart hvorvidt ei gitt fil er ett disk-image eller et digitalt foto).
> Og jeg skal ikke engang begynne å skrive om at Windows ikke ser
> forskjell på STORE og små bokstaver.
Jeg antar det er fordi du egentlig ikke har noen argumenter, men bare UNIX-fanatismen din som skinner gjennom :)
Case-sensitive filsystemer er totalt uintuitivt for mennesker; det er kun en bieffekt av at "a" og "A" har forskjellige binære verdier, og grunnen til at man i UNIX-verdenen fremdeles klamrer seg til denne politikken er utelukkende av legacy-årsaker fordi det opprinnelig gjorde det noe enklere i en tid da både programmerings- og maskinressurser var begrenset. Enhver UNIX-administrator med vettet i behold vil i dag være enig i at det er dårlig praksis å utnytte dette faktum og begynne å lagre filer med samme navn men med forskjellig caps - nettopp fordi det er forvirrende for brukerne.
Dessuten "ser" Windows forskjell på store og små bokstaver. Både FAT og NTFS er case-preserving filsystemer, dvs. hvis du lagrer en fil som "bLaNdEtCaPs.txt" vil den bli lagret som akkurat det i filsystemet, men vil kunne aksesseres med både "BLANDETCAPS.txt" og "blandetcaps.txt" - noe som etter min mening er det eneste fornuftige måten å gjøre dette på. Hvis det på noen måte skaper ambiguitets-problemer for deg har du valgt en feil navnepolitikk på filene dine i utgangspunktet.