Lähtökohta

Minulla on DVD-levy, jolle on poltettu tiedostoja Windowsissa. Tiedostojen joukossa on sellaisia, joiden nimissä on skandinaavisia kirjaimia.

Lataan levyn tietokoneen DVD-asemaan, jolloin se liitetään tiedostojärjestelmään. Avaan levyn sisällön selailtavakseni Nautilus-tiedostoselaimella.

Ongelma

Skandinaavisia kirjaimia sisältävissä tiedostonimissä ne ovat korvautuneet kysymysmerkeillä, ja tiedostonimen perässä lukee (virheellinen merkistökoodaus). Tiedostonimen kopiointi avaamaani Pääte-ikkunaan ei toimi, jos poimin tiedoston Nautiluksen ikkunasta ja vedän ja pudotan sen Pääte-ikkunaan.

Ongelman syy

Levyä ei ole liitetty UTF-8 -merkistökoodausta käyttäen.

Ratkaisu

Muutan /etc/fstab -tiedostossa olevaa CD/DVD -asemani määrittelevää riviä. Ennen muutoksia rivi näyttää seuraavanlaiselta:

/dev/scd0  /media/cdrom0  udf,iso9660  user,noauto,exec  0 0

Lisään liittämisparametreihin merkistökoodauksen, jonka jälkeen rivi näyttää seuraavanlaiselta:

/dev/scd0  /media/cdrom0  udf,iso9660  user,noauto,exec,utf8  0 0

Otan levyn ulos DVD-asemasta, ja lataan sen sitten uudestaan sisään. Kun tämän jälkeen selaan levyn sisältöä Nautiluksella, tiedostonimissä olevat skandinaaviset kirjaimet näytetään kuten pitää, ja sellaisia sisältävien tiedostonimien kopionti Pääte-ikkunaan vetämällä ja pudottamalla toimii.

Huomautus

Tietokoneessa, johon olen asentanut Hardy Heronin siihen päivittämisen sijasta, utf8 -parametri oli fstab-tiedoston DVD-asemamäärittelyssä valmiina.

Lähtökohta

Käyttöjärjestelmäni on suomenkielinen, eli locale-komennon antama tuloste näyttää seuraavalta:

LANG=fi_FI.UTF-8
LC_CTYPE="fi_FI.UTF-8"
LC_NUMERIC="fi_FI.UTF-8"
LC_TIME="fi_FI.UTF-8"
LC_COLLATE="fi_FI.UTF-8"
LC_MONETARY="fi_FI.UTF-8"
LC_MESSAGES="fi_FI.UTF-8"
LC_PAPER="fi_FI.UTF-8"
LC_NAME="fi_FI.UTF-8"
LC_ADDRESS="fi_FI.UTF-8"
LC_TELEPHONE="fi_FI.UTF-8"
LC_MEASUREMENT="fi_FI.UTF-8"
LC_IDENTIFICATION="fi_FI.UTF-8"
LC_ALL=

Kun suoritan Päätteestä komennon ls /asdfgh, eikä hakemistoa /olematonhakemisto ole, komento antaa seuraavanlaisen virheilmoituksen:

ls: tiedostoa /asdfgh ei voi käsitellä: No such file or directory

Virheilmoituksen alkuosa on suomenkielinen, kuten sen kuuluu ollakin.

Ongelma

Suomenkielinen virheilmoitus on hakusanana paljon tehottomampi kuin englanninkielinen virheilmoitus, kun etsin ratkaisua ongelmaan. Haluan suorittaa komennon siten, että näen sen antaman virheilmoituksen englanninkielisenä.

Ratkaisu

Suoritan komennon siten, että nollaan kielen komennon suorittamisen ajaksi oletukseensa, seuraavasti:

LC_ALL=C ls /asdfgh

Tällöin komennon antama virheilmoitus näkyy kokonaan englanninkielisenä:

ls: cannot access /asdfgh: No such file or directory

Komennon suorittamisen jälkeen kieliasetus palautuu ennalleen, eli virheilmoitukset ja muut tulosteet näytetään jälleen suomenkielisinä.

Maanantaina 28.4.2008 tuomittiin kalifornialaisessa oikeusistuimessa muuan Hans Reiser vankeuteen murhasta. Murhaoikeudenkäynnistään muidenkin tietoisuuteen noussut Reiser tunnettiin alkujaan Linux-käyttäjien piirissä hänen kehittelemästään tiedostojärjestelmästä, ReiserFS:stä.

Minäkin olen ReiserFS:n käyttäjä. Olen alustanut sillä kolme osiota kiintolevyltäni: /homen, /varin ja /mnt/Arkisto -osion. Koska ReiserFS:n kehittäjää odottaa näillä näkymin vähintään 25 vuoden vankilatuomio, tiedostojärjestelmän tulevaisuus näyttää tällä hetkellä hyvin epävarmalta. Näin siitäkin huolimatta, että jotkut arvelevat Reiserin vankilatuomion vain parantavan hänen tiedostojärjestelmänsä kehitystä joko ilman häntä tai hänen avullaan vankilasta käsin.

Kuitenkin esimerkiksi aiemmin ReiserFS:ää oletustiedostojärjestelmänä SuSE Linux -käyttöjärjestelmässään käyttänyt Novellkin on jo ReiserFS:n pääkehittäjän juridisten vaikeuksien pelottamana siirtynyt käyttämään ext3-tiedostojärjestelmää. ReiserFS:n tilanteen takia päätin hiukan tutkia mitä vaihtoehtoja sille olisi tarjolla. Ext3:n ohella varteenotettavimpia, eli juuri tällä hetkellä realistisia vaihtoehtoja ovat JFS, XFS ja ZFS. Käyn nämä seuraavassa läpi käänteisessä järjestyksessä, lopusta alkuun.

ZFS:ää pidetään ehkäpä lupaavimpana tämänhetkisistä tiedostojärjestelmistä. ZFS:n ongelmana on kuitenkin sen käyttöä säätelevä lisenssi, CDDL. Vaikka CDDL luetaankin vapaiden lisenssien joukkoon, se ei ole GPL-yhteensopiva. Niinpä ZFS:ää ei löydy Linux-ytimestä, eikä tule löytymäänkään niin kauan kuin lisenssiä ei muuteta — eikä välttämättä sittenkään, riippuen siitä minkä version GPL:stä ZFS:n kehityksestä vastaava Sun Microsystems valitsee.

Linuxin kanssa ZFS:ää voi kyllä käyttää, mutta se toimii silloin niinsanottuna userland-sovelluksena, eli ytimen ulkopuolella. /homen kaltaisen, ei-kriittisen osion kohdalla tällainen menettely tiedostojärjestelmän kanssa ehkä vielä joten kuten menettelisi. /var-osion olisi kuitenkin syytä toimia kaikissa olosuhteissa, joten sen liittämisen olisi parasta nojata suoraan ytimessä olevaan koodiin.

XFS on SGI:n kehittämä tiedostojärjestelmä, jonka etu on suorituskyky, joka on suhteessa muihin sitä parempi, mitä isommista tiedostoista on kyse. XFS:n ohella myös IBM:n kehittämä JFS pärjää hyvin juuri isojen tiedostojen käsittelyssä, kuitenkin sillä erotuksella, että JFS käyttää vähemmän suoritintehoja.

Kaikki ei kuitenkaan ole ruusuisaa, mitä näihin vaihtoehtoihin tulee.

XFS:llä huhutaan olevan vakausongelmia. Asteen varteenotettavampia ovat kuitenkin puheet siitä, että XFS käyttäytyy huonosti silloin, kun koneesta saattaa katketa virta, tai se kaatuu, tai sammutus tapahtuu muuten vain ennakoimattomasti. Tämä johtuu siitä, että XFS on suunniteltu palvelinkäyttöön. Palvelimet pyörivät yleensä varsin luotettavasti (esimerkiksi sähkönsaanti on turvattu UPS:llä), joten tiedostojärjestelmää suunniteltaessa ei kotikoneita koskevista epävakausongelmista selviytymiseen ole tarvinnut panostaa.

JFS:n osalta tällaiset huhut eivät ole yhtä laajalle levinneitä, mutta se saattaa ihan hyvin johtua vain siitä, että itse tiedostojärjestelmän käyttökään ei ole kovin laajalle levinnyttä. Ongelmista ei siis ehkä ole raportoitu siksi, ettei raportoijiakaan ole, enkä pidäkään JFS:n vakautta kotikäytössä riittävän hyvin testattuna voidakseni luottaa siihen. Yksi tunnettu ja tunnustettu ongelma JFS:llä on, ja se on Windows-ympäristöistä tuttu tiedostojen pirstaloituminen.

Kaiken huipuksi JFS:n ja XFS:n tulevaisuus näyttää juuri nyt yhtä epävarmalta kuin ReiserFS:n tulevaisuus, joskin vähän erilaisista syistä. XFS:n kehitys kärsii SGI:n taloudellisista vaikeuksista. IBM on puolestaan menettänyt kiinnostuksensa JFS:n kehittämiseen, koska Linux-maailman isot yritysnimet, Novell ja Red Hat ovat lopettaneet tukensa sille.

Jäljelle jää näin ollen ext3. Sen etu on iän, ja Linuxin levinneisyyden myötä laajalti tehdyn testauksen tuoma vakaus ja luotettavuus. Löytyy tietysti niitäkin, jotka pitävät tätä mainetta ansaitsemattomana, ja ext3:a kaikkein epäluotettavimpana, mutta ext3:n tuki on kuitenkin kiistatta Linuxissa ja eri Linux-jakeluversioiden kesken kaikkein paras. Ext3:n kiistaton haittapuoli taas perustuu samaan asiaan kuin sen edutkin, eli ikään. Koska ext3 on rakennettu aiempien versioiden (ext ja ext2) pohjalta yhteensopivuus huomioiden, se on jäänyt vauhdissa auttamatta jälkeen yllä mainituista, uudemmista tulokkaista.

Juuri tällä hetkellä tilanne näyttää siis kaikin puolin heikolta. Tässä luetelluista tiedostojärjestelmistä ext3 on oikeastaan ainoa, jota voisin edes harkita, jos nyt ryhtyisin vaihtamaan ReiserFS:llä alustettujen /var- ja /home-osioitteni tiedostojärjestelmää. Siitäkin maksaisin sitten todennäköisesti käytännössä hinnan kiintolevytoimintojen hidastumisena. Valitsisin kuitenkin ext3:n kaikille osioille siinä tapauksessa, että olisin nyt vasta asentamassa käyttöjärjestelmää, ja kiintolevy täytyisi joka tapauksessa alustaa johonkin muotoon.

Arkisto-osiolle voisin kyllä ottaa käyttöön JFS:n tai XFS:n niiden mahdollisesta epäluotettavuudesta välittämättä, koska sille osiolle en pitkiksi ajoiksi varastoi muuta kuin sellaista tavaraa, jonka olen jo kertaalleen polttanut rompulle. Näiden etu olisi jo mainittu suurten tiedostojen käsittelyn nopeus, joka pääsisi oikeuksiinsa, koska osio sisältää lähes yksinomaan vähintään useiden megatavujen kokoisia tiedostoja (musiikkia ja videota). Tuen jatkuvuudessa en tällä muutoksella edellä kerrotun perusteella siis kuitenkaan voittaisi mitään.

/var on täynnä pikkutiedostoja, joten ReiserFS sopii sille kuin nyrkki silmään, sillä ReiserFS:n valtti on nimenomaan nopeus pienten tiedostojen kanssa. /home sisältää sekalaista tavaraa, mutta paljon pieniä (asetus-) tiedostoja sekin, joten ei ReiserFS siihenkään väärä valinta alunalkujaan ollut.

ReiserFS:n tukikaan ei tietenkään ole loppumassa ihan seinään, sillä olen kaikkea muuta kuin yksi harvoista sitä käyttäessäni. Koska vaihtoehtojen suhteen tilanne on tällä hetkellä melko kehno, olenkin päättänyt pitää pääni kylmänä, ja katsella mihin suuntaan asiat kehkeytyvät. Jos optimistiset ennusteet pettävät, ReiserFS:n kehitys tyssää Hans Reiserin vankilatuomioon. Jos tiedostojärjestelmä alkaa sen jälkeen osoittaa ikääntymisen merkkejä, täytyy tutkia, onko tilanne vaihtoehtojen suhteen silloin yhtään parempi.

Lähtökohta

Kotihakemistossani on esimerkki.abw -niminen, AbiWordilla luotu tiedosto. Tiedoston sisältö on muotoiltu XML-kielellä.

Ongelma

Haluan tulostaa tiedoston komentotulkki-ikkunassa siten, että mitään sen sisältämiä XML-koodisanoja, eli mitään merkkien < ja > väliin jäävää sisältöä ei näytetä.

Ratkaisu

Suoritan seuraavan komennon:

cat ~/esimerkki.abw | sed 's/<[^>]*>//g' | sed '/./,/^$/!d'

Komento tulostaa tiedoston sisällön komentotulkissa ilman muotoilukoodeja. Lisäksi jälkimmäinen sed-komento korvaa peräkkäiset tyhjät rivit tulosteessa yhdellä tyhjällä rivillä.

Ubuntu 8.04, koodinimeltään Hardy Heron, on julkaistu, ja on nyt ladattavissa Ubuntu Suomen sivuilta. Hardy Heron on pitkällä aikavälillä tuettu eli LTS-versio. Muista, puolitoista vuotta tuetuista versioista poiketen sitä siis tuetaan seuraavat kolme vuotta. Tietoa uusista ominaisuuksista sekä muita lisätietoja tuoreesta jakeluversiosta löytyy esimerkiksi julkaisutiedotteesta ja julkaisumuistiosta.

Minä otin varaslähdön uuteen versioon viikko sitten, ja siitä lähtien tämän blogin merkinnät ovat perustuneet ja tulevat jatkossakin perustumaan Hardy Heronin käyttöön ainakin seuraavan version (jonka koodinimi on Intrepid Ibex) julkaisuun saakka.

Lähtökohta

Pakettienhallinnassa gnupg on asennettuna. Kotihakemistossani on salainen.txt -niminen tiedosto, joka sisältää salaisen viestin.

Ongelma

Haluan salata salaisen viestin GPG:llä siten, että salauksessa käytetyn salasanan tietäminen riittää salatun tiedoston avaamiseen — avaintiedostoa ei siis tarvita.

Ratkaisu

Käytän GPG:n symmetristä salausta tiedoston salaamiseen, komentamalla seuraavasti:

gpg -c ~/salainen.txt

Komennon suorittamisen jälkeen GPG kysyy tiedoston salauksessa käytettävää salasanaa kahdesti. Sen jälkeen kotihakemistossani on alkuperäisen tiedoston lisäksi salainen.txt.gpg -niminen tiedosto, jonka avaamiseen GPG:llä tarvitaan salasana. Hävitän alkuperäisen tiedoston srm-komennolla.

Salatun tiedoston avaaminen GPG:llä tapahtuu seuraavalla komennolla:

gpg -d ~/salainen.txt.gpg > ~/salainen.txt

Komennon suorittamisen jälkeen kotihakemistossani on jälleen salainen.txt -niminen tiedosto, joka sisältää alkuperäisen viestin salaamattomana.

Huomautus

Viestiä purettaessa GPG antaa seuraavanlaisen varoituksen:

gpg: VAROITUS: viestin eheyttä ei oltu suojattu

Varoituksen voi ilmeisesti jättää huomiotta.

Lähtökohta

Haluan tarkastella komentoriviltä esimerkki.mov -tiedoston sisältöä.

Ongelma

Tiedoston sisältö on videodataa, joten sitä ei pysty tarkastelemaan sujuvasti cat-komennolla.

Ratkaisu

Asennan Synaptic-pakettienhallinnassa hexcat-paketin, minkä jälkeen voin tarkastella tiedoston sisältöä sivutettuna komentokehoteikkunassa seuraavalla komennolla:

hexcat esimerkki.mov | less

Lähtökohta

Tietokoneessani on Ubuntun lisäksi toisella kiintolevyosiolla Windows-käyttöjärjestelmä. Ubuntun asennuksen yhteydessä olen ilmoittanut paikalliseksi aikavyöhykkeekseni (eli tietokoneeni sijainniksi) Suomen aikavyöhykkeen (Europe/Helsinki).

Ongelma

Kun Suomessa siirrytään kesäaikaan, Ubuntun työpöydän paneelissa oleva kello ei ole siirtynyt kesäaikaan. Kesäaikaan siirtymisen jälkeen tietokoneeni kello on siis tunnin Suomen aikaa jäljessä. Järjestelmä → Ylläpito -valikon Aika ja päiväys -sovellus ilmoittaa aikavyöhykkeekseni Europe/Mariehamn.

Ongelman syy

Tietokoneeni kello on asetettu paikalliseen aikaan koordinoidun yleisajan (UTC) sijasta. Ubuntu on tietoinen tästä valinnasta, ja tulkitsee sen siten, että Windows huolehtii kesä- ja talviaikaan siirtymisistä. Jos en ole käynnistänyt Windowsia kesäaikaan siirtymisen tapahduttua, kello näyttää tuntia vähemmän kuin sen pitäisi, jolloin Ubuntu ilmeisesti olettaa aikavyöhykkeen muuttuneen.

Ratkaisu

Sammutan Ubuntun ja käynnistän Windowsin, jolloin Windows asettaa tietokoneen kellon kesäaikaan. Kun sen jälkeen sammutan Windowsin ja käynnistän uudelleen Ubuntun, työpöydän paneelin kellonaika on Suomen kesäaika. Valitsen sen jälkeen Järjestelmä → Ylläpito-valikon Aika ja päiväys -sovelluksessa aikavyöhykkeekseni jälleen Europe/Helsinki.

Huomautuksia

• Jos siirryn käyttämään yksinomaan Ubuntua, voin asettaa tietokoneen kellon koordinoituun yleisaikaan ja ilmoittaa siitä asettamalla /etc/default/rcS -tiedostossa olevan UTC-muuttujan arvosta no arvoksi yes. Sen jälkeen Ubuntu osaa laskea kulloinkin vallitsevan paikallisen ajan tietokoneen kellon ja asettamani paikallisaikavyöhykkeen perusteella.
• En tiedä mistä Ubuntun asennusohjelma päätteli, että tietokoneeni kello on asetettu paikalliseen aikaan. Sen pitäisi tiettävästi olettaa kellon olevan yleisajassa. Ehkä se otti yhteyden aikapalvelimeen ja vertasi sieltä saamaansa aikaa tietokoneeni kellon näyttämään aikaan.
• Jos aikavyöhykkeen korjaa ennen Windowsin käynnistämistä, se on Ubuntun uudelleenkäynnistämisen jälkeen jälleen Europe/Mariehamn.

Lähtökohta

Minulla on joukko tiedostoja joiden nimissä on ä- ja ö-kirjaimia. Kaikki tiedostonimet koostuvat yksinomaan pienistä kirjaimista, eli kirjainmerkeistä a-ö. Haluan muuntaa nimet siten, että ä:t korvautuvat a-kirjaimilla ja ö:t o-kirjaimilla. Aion käyttää muuntamiseen tr-komentoa.

Ongelma

Tr-komento tulkitsee sille antamiani skandinaavisia kirjaimia sisältäviä muunnossääntöjä väärin ja ennalta-arvaamattomalla vaikuttavalla tavalla. Seuraavassa on tästä esimerkkejä:

$ echo tiedostonnimi-jossa-on-ä | tr ä a
tiedostonnimi-jossa-on-aa
$ echo tiedostonnimi-jossa-on-ää | tr ä a
tiedostonnimi-jossa-on-aaaa
$ echo tiedostonnimi-jossa-on-äö | tr ä a | tr ö o
tiedostonnimi-jossa-on-aaao
$ echo tiedostonnimi-jossa-on-öö | tr ä a | tr ö o
tiedostonnimi-jossa-on-aoao
$ echo tiedostonnimi-jossa-on-öä | tr ä a | tr ö o
tiedostonnimi-jossa-on-aoaa

Ongelman syy

Tr-komento ei tue komentotulkissani käytössä olevaa UTF-8 -koodausta.

Ratkaisu

Käytän tr-komennon sijasta sed-komentoa skandinaavisten kirjainten muuntamiseen, seuraavalla tavalla:

for file in *ä*; do mv $file `echo $file | sed -e 's/ä/a/g'`; done
for file in *ö*; do mv $file `echo $file | sed -e 's/ö/o/g'`; done

Ongelma

Haluan listata komentoriviltä nykyisessä hakemistossa olevien alihakemistojen sisältämien tiedostojen määrän kunkin alihakemiston osalta.

Ratkaisu

for dir in *; do echo -n "$dir: " && echo $dir/* | wc -w; done

Huomautus

Ratkaisussa annettu komento ei erottele nykyisen hakemiston juuressa olevia tiedostoja varsinaisista alihakemistoista, vaan listaa nekin ikään kuin ne olisivat alihakemistoja, jotka sisältävät yhden tiedoston.