Muistitikut paremmilla tiedostojärjestelmillä

[Tomin]

Osioin muistitikkuni ext2:ksi (ext4:kin harkitsin, ilman journalointia). Mietin vain miten hoitaisin oikeuspolitiikan, kun aiemminhan siitä ei ole juuri tarvinnut FAT32:n kanssa välittää vaan aina on kaikki oikeudet (tai ei mitään). Eli tilanne on se, että on siirrettävä osio jota käytetään eri koneiden kanssa (eri jakeluja yms.) ja aina pitäisi päästä käsiksi periaatteessa kaikkiin tiedostoihin käytössä olevalla käyttäjällä. Tietoturvan osalta haetaan siis suurin piirtein yhtä huonoa systeemiä kuin FAT32:n tapauksessa tai sitten parempaa jos ei tarvitse tehdä kompromisseja.

Mietin paria ratkaisumahdollisuutta, joista tosin en pienellä etsimisellä (hakukoneella englannin kielellä etsin) löytänyt mitään hyödyllistä, joten toteuttaminen on vähän hukassa.

Yksi mahdollisuus voisi olla asettaa tiedostojärjestelmään sellainen bitti, ettei tietojen käyttäjän oikeuksia huomioida oletuksena. Onkohan tälläistä olemassa?

Toinen olisi joku yleinen ryhmä id, mutta sellaista ei taida ainakaan eri jakeluille yhteisenä olla? Archissa näkyy olevan users luotuna, en muista oliko valmiissa asennuksessa vai lisäsinkö jostain syystä joskus. Voiko muuten tiedostojärjestelmälle asettaa erikseen oletusryhmän johon uudet tiedostot luodaan?

Kiitän neuvoista. Tutkin jo itse tune2fs:n man-sivua hieman, mutta en sieltä mitään kovin hyödyllistä huomannut. Varatut blokit huomasin jo vähentää nollaan ettei niitä säästellä turhaan. Tätä asiaa olisi varmaan muutenkin ihan hyvä miettiä, jos haluaa että tikuilla käytettäisiin muutakin kuin Microsoftin FAT:ia. Nämä Unix-tiedostojärjestelmät ovat ehkä teknisesti parempia, mutta tämmöiset ominaisuudet (hyviä kyllä yleensä) tekevät niiden käytöstä tietyissä tilanteissa vähän hankalaa.

[Karvameduusa]

Itselläni on ainakin kaikki alustettu tikut auennut distrosta riippumatta. Ainakin Ext4 formaatissa ja tikut olen tehnyt gnome-disk-utility:llä. Ohjelma on oletuksena asennettu Gnome:lle.

[SuperOscar]

Osioin muistitikkuni ext2:ksi (ext4:kin harkitsin, ilman journalointia).

Minä kerran kokeilin ext3:a, ja jouduin ongelmiin. Guuglaamalla tuli vastaan lähinnä neuvo, että tikuilla kannattaa käyttää ext2:ta. Journaloinnin estämistä en tosin kokeillut.

Eli tilanne on se, että on siirrettävä osio jota käytetään eri koneiden kanssa (eri jakeluja yms.) ja aina pitäisi päästä käsiksi periaatteessa kaikkiin tiedostoihin käytössä olevalla käyttäjällä.

Eikö riitä, että luot tikulle kansion (tai kansioita), jolla on oikeudet 777? Eihän se tietysti koko tikkuun oikeuksia anna, mutta siitä kansiosta alaspäin kyllä.

Toisaalta on minullakin huonoja kokemuksia oikeuksien säilymisestä eri tilanteissa. Aikanaan Tampereen yliopiston WWW-sivuja palvelimelle siirrettäessä tuli ongelmaksi, että siirrossa luotujen uusien tiedostojen kirjoitusoikeudet olivat vain tekijällä – kaikista sticky-biteistä huolimatta. Ylläpito ratkaisi ongelman lopulta luomalla cron-skriptin, joka chmodasi tiedostot aika ajoin. Käyttäjän kulloinenkin umask tuntuu aina ohittavan yritykset kansiorakenteen oikeuksia säätämällä asettaa siellä olevien tiedostojen oikeudet.

[Tomin]

Eli tilanne on se, että on siirrettävä osio jota käytetään eri koneiden kanssa (eri jakeluja yms.) ja aina pitäisi päästä käsiksi periaatteessa kaikkiin tiedostoihin käytössä olevalla käyttäjällä.

Eikö riitä, että luot tikulle kansion (tai kansioita), jolla on oikeudet 777? Eihän se tietysti koko tikkuun oikeuksia anna, mutta siitä kansiosta alaspäin kyllä.

Niin, se kyllä toimisi, mutta sitä haluaisin välttää. Varmaankaan sen tiedostojärjestelmän juuren inoden oikeuksia ei voi asettaa (vaan vain liitospisteen, joka ei tietenkään ole siellä tikulla)?

[Ganymedes]

Eli tilanne on se, että on siirrettävä osio jota käytetään eri koneiden kanssa (eri jakeluja yms.) ja aina pitäisi päästä käsiksi periaatteessa kaikkiin tiedostoihin käytössä olevalla käyttäjällä.

Eikö riitä, että luot tikulle kansion (tai kansioita), jolla on oikeudet 777? Eihän se tietysti koko tikkuun oikeuksia anna, mutta siitä kansiosta alaspäin kyllä.

Niin, se kyllä toimisi, mutta sitä haluaisin välttää. Varmaankaan sen tiedostojärjestelmän juuren inoden oikeuksia ei voi asettaa (vaan vain liitospisteen, joka ei tietenkään ole siellä tikulla)?

Miksi 777:ta pitäisi välttää? Juureen se ei tehonne, kuten tuossa jo sanotkin - mutta eihän juureen, siis periaatteessa, muutenkaan pitäisi kirjoittaa mitään muuta kuin yksi tai joskus useampi hakemisto.

Ei ulkoisella medialla ole mitään tiedostojärjestelmä-specifistä tietoturvaa - kaikenhan sieltä voi lukea, jos median saa käsiinsä. Sama pätee toki sisäisiin levyihinkin, niiden käsiinsä saaminen on vain vaikeampaa. Kryptaukset ja tällaiset luovat vasta tietoturvan siinä tapauksessa että media joutuu vääriin käsiin.

Jos et halua käyttää FAT32:ta, niin käytä jotain sellaista tiedostojärjestelmää, jonka oikeuspolitiikkaa ei kunnioiteta Ubuntussa. Tällainen on esim. NTFS. Silloin pitää kuitenkin olla Windows-kone jossakin käytettävissä, koska Ubuntu ei osaa kaikenlaisia tiedostojärjestelmän korjauskonsteja NTFS:lle kuten Windows - tai sitten ottaa tässä pienen riskin, jos asialla ei ole niin suurta väliä.

[Tomin]

Eli tilanne on se, että on siirrettävä osio jota käytetään eri koneiden kanssa (eri jakeluja yms.) ja aina pitäisi päästä käsiksi periaatteessa kaikkiin tiedostoihin käytössä olevalla käyttäjällä.

Eikö riitä, että luot tikulle kansion (tai kansioita), jolla on oikeudet 777? Eihän se tietysti koko tikkuun oikeuksia anna, mutta siitä kansiosta alaspäin kyllä.

Niin, se kyllä toimisi, mutta sitä haluaisin välttää. Varmaankaan sen tiedostojärjestelmän juuren inoden oikeuksia ei voi asettaa (vaan vain liitospisteen, joka ei tietenkään ole siellä tikulla)?

Miksi 777:ta pitäisi välttää?

Ymmärsit väärin. Tarkoitin, että haluaisin välttää sitä, että tikun juureen tulisi vain yksi hakemisto, mielummin haluaisin sen juuren oikeuksiksi 777, mutta sitä ei ilmeisesti voi tehdä.

Voisin tietysti harkita suunnittelevani hakemistorakenteen etukäteen ja tehdä valmiiksi sopivan määrän hakemistoja. Kaikilla koneillahan ei ole mahdollista olla root, joten myöskään aina noita hakemistoja ei voi lisätä tai myöskään muutella oikeuksia.

[Ganymedes]

...
Voisin tietysti harkita suunnittelevani hakemistorakenteen etukäteen ja tehdä valmiiksi sopivan määrän hakemistoja.
...

Ei tarvitse tehdä kuin yksi hakemisto valmiiksi, esim. nimellä "data", ja antaa sille halutut oikeudet. Se, että juureen ei voi kirjoittaa, on tässä skenariossa se mitä halutaankin.

[Tomin]

...
Voisin tietysti harkita suunnittelevani hakemistorakenteen etukäteen ja tehdä valmiiksi sopivan määrän hakemistoja.
...

Ei tarvitse tehdä kuin yksi hakemisto valmiiksi, esim. nimellä "data", ja antaa sille halutut oikeudet. Se, että juureen ei voi kirjoittaa, on tässä skenariossa se mitä halutaankin.

Öö, miten niin halutaan?

Minä halusin että tikkua voisi käyttää kuten olen tottunut muistitikkuja käyttämään. En pidä ylimääräisistä hakemistoista hakemistorakenteessani. Kyllä minä sen ymmärsin, että sitten niihin jo luotuihin hakemistoihin voi tehdä uusia, mutta tuntuu hölmöltä avata tikun hakemisto tiedostoselaimeen ja sitten tehdä uusi klikkaus data-hakemistoon (tai mikä onkaan nimeltään) ja sitten vasta valita esimerkiksi Asiakirjat johon on tungettu käsiteltävä tiedosto. Esimerkit alla.
Toivottu:

Koodia: [Valitse]

.
├── Asiakirjat
│   └── Koulu
├── Kuvat
│   ├── Kamera
│   └── Loma
├── Projektit
└── Videot
Epätoivottu:

Koodia: [Valitse]

.
└── data
    ├── Asiakirjat
    │   └── Koulu
    ├── Kuvat
    │   ├── Kamera
    │   └── Loma
    ├── Projektit
    └── Videot
Mutta ilmeisestikään tuosta data-hakemistosta ei ole mahdollista päästä eroon? Tiedostojakin laittaisin mielelläni kaikille tasoille.

Tarkoitus ei nyt ole olla vastarannankiiski tai muutenkaan, vaan haluaisin selvittää voiko näiden tiedostojärjestelmien oikeuksia määrätä jotenkin "tyhmiksi", jotta ne toimisivat enemmän kuten "tyhmät" tiedostojärjestelmät. Pidän kyllä esimerkiksi suoritusoikeudesta, jottei käy kuten FAT:in kanssa ja jatkuvasti kysellä haluatko suorittaa vai katsella, mutta ryhmän ja käyttäjän haluaisin unohtaa.

[Ganymedes]

Vastaukseni olivat enemmän yleisluonteisia, koska enhän tiedä mitä olet tekemässä ja miksi varsinaisesti kysyt. En tiedä kyllä vieläkään, mutta edellisestä voisi päätellä, että olet tekemässä tätä vain itsellesi.

Tällöin ongelmaasi ei välttämättä ole ollenkaan. Nimittäin jos järjestät oman käyttäjätunnuksesi "pekka", olemaan numero 1001 kaikilla käyttämilläsi koneilla, niin silloin "pekalla" on automaattisesti samat oikeudet tikkuun kaikilla koneilla.

Se mihin edellä viittasin on se, että "datasta" ei käsittääkseni pääse eroon yleisessä tapauksessa (jos ei joku keksi jotakin aivan muuta) ja sillä tavalla asia hoituu.

Toisaalta data-levyillä tuollainen käyttötapa on aina suositeltava. Yleensä juureen ei kirjoiteta mitään sen jälkeen kun levy otetaan käyttöön. Juureen kirjoitus on hyvin huono idea, koska koko levyn backup ei onnistu kunnolla, koska juureen systeemi kirjoittelee sitä sun tätä (riippuen järjestelmästä: recycle, trash, lost+found, pagefile jms). Tällöin joutuu myös luettelemaan kaikki hakemistot joista otetaan backup ja luetteloa joutuu pitämään yllä, jotta backup jatkaa toimintaansa. Jos tulee uusi hakemisto, joka puuttuu listalta, niin se jää varmistamatta.

Yleensä backupit, synkronoinnit ja siirrot tehdään jollakin luotettavalla menetelmällä, kuten rsync (Windowsissa robocopy), jolloin tarvitaan aika paljon editointia jos hakemistoja on paljon. Nythän lisäksi tulevat kaikenlaiset vipujen muutokset, jotka muutostilanteissa pitää myös ottaa huomioon (esim. alkuvaiheessa vivun "--delete-before" käyttäminen tai käyttämättä jättäminen). Jos päätasolla on vain yksi hakemisto, yksi komento riittää, se toimii aina eikä mitään voi unohtua. Muutostenteko on myös mahdollisimman yksinkertaista.

Kysyit tikusta - yleisessä tapauksessa sitäkin synkronoidaan ja siitä pitää ottaa varmennuksia, joten tämä yhden päähakemiston käyttö on suositeltavaa.

... mutta toisaalta, tapauksesi voi olla jotakin muutakin ...

Vertailun vuoksi, Ubuntun tapa, jossa datat menevät oletuksena "pekka/home":n alle onkin arvelluttava, eikä kestäisi serverikäytössä. Asia olisi muuten ok, mutta kun datan joukossa on paljon muutakin, jotka esim. synkrointi ja varmistustilanteessa elävät aivan omaa elämäänsä ... siellä on mm.:

- ohjelmien konfigurointitiedostoja suuri määrä, joiden varmistaminen on lähes kokonaan turhaa (mutta on siellä tarpeellisiakin joukossa, ehkä alle 1%)
- tilapäistiedostoja erittäin suuri lukumäärä, joiden varmistaminen on kokonaan turhaa
- kiusaus on suuri, sijoittaa tänne ajettavia ohjelmia
- piilohakemistoja, jotka ovat oikeasti dataa eikä niiden pitäisi olla samassa paikassa piilotilapäistiedostojen joukossa, vaan niiden pitäisi olla näkyviä

Tämä on tietysti ohjelmienkin asia, että mihin ne haluavat sijoittaa tiedostonsa, eikä välttämättä "Ubuntun vika".

[Tomin]

Jo ensimmäisessä viestissä kirjoitin:

Osioin muistitikkuni ext2:ksi (ext4:kin harkitsin, ilman journalointia). Mietin vain miten hoitaisin oikeuspolitiikan, kun aiemminhan siitä ei ole juuri tarvinnut FAT32:n kanssa välittää vaan aina on kaikki oikeudet (tai ei mitään). Eli tilanne on se, että on siirrettävä osio jota käytetään eri koneiden kanssa (eri jakeluja yms.) ja aina pitäisi päästä käsiksi periaatteessa kaikkiin tiedostoihin käytössä olevalla käyttäjällä. Tietoturvan osalta haetaan siis suurin piirtein yhtä huonoa systeemiä kuin FAT32:n tapauksessa tai sitten parempaa jos ei tarvitse tehdä kompromisseja.

Idea olisi siis käyttää tikkua joskus mukana kuljetettavien tiedostojen käyttöön (pilvipalvelutkin ovat kyllä ihan hyviä, mutta palataan nyt kivikaudelle). Varmuuskopioitakaan ei ole tässä tapauksessa tarkoitus miettiä, niihin on systeemit omilla koneilla. Muuten tikulle tungettu data on luokkaa "latasin netistä toisella koneella ja varmuuskopioiden tekemisessä ei ole ideaa". Kone johon tikku kytketään ei välttämättä ole oma, eikä siihen ole root-oikeuksia tai muutenkaan lupaa tehdä muutoksia. Lisäksi siinä voi olla melko mielivaltainen jakelu ja käyttäjän id:t vaihtelevat paljon (jo pelkästään siksi ettei käyttäjä ole aina se ensimmäisenä luotu).

En ymmärrä miksi kukaan tallentaisi noita ohjelmien asetuksia tikuille, kun eivät ne muutenkaan yleensä niitä sinne oletuksena pistä ja käskyttämälläkin aika hankalasti (normaalisti kotihakemistoon, ~/.config tai vastaava). Roskikset ja muut menevät jos silläkin ettei välitä piilohakemistoista, jos tarvitsee kopioida tikun sisältöä. Joskushan tikuilla oli noita PortableApps-juttuja, mutta ne on tosiaan olleet vain Windows-maailmaan ja siksi tässä tapauksessa aika epärelevantteja. Linux-jakeluissahan yleensä on kaikki tarpeellinen mukana. En minä käytä tikkuja siihen, että siirrän työpöytäni toiseen koneeseen. Jos tekisin niin, laittaisin koko jakelun tikulle (mitä meinasin kokeilla, mutta siinä ei liene tälläisiä ongelmia).

Eli jos pistän tikulle muutamia tiedostoja, vaikkapa kotivideoita, jotka vien sukulaisen luokse (jonka konetta nyt en jostain syystä satu ylläpitämään vaikka Linuxia käyttääkin ) niin miksi en voisi laittaa ko. tiedostoa suoraan tikulle? Miksi sillä pitäisi olla data-hakemisto? Mielestäni tarpeetonta. Tietenkin siinä vaiheessa kun tikulla alkaa olla kymmeniä tiedostoja on syytä rakennella sinne edellisessä viestissä esittämäni kaltaista hakemistorakennetta, minkä varmaan teenkin, mutta kyllä sieltä aina välillä tulee tuhottua kokonaisia hakemistoja, jotka on luotu joskus puolisen vuotta sitten. Varmuuskopioina tässäkin tapauksessa toimivat koneella olevat alkuperäiset tiedostot (jotka ovat varmuuskopioituna jossain muualla).

[Tomin]

Kirjoitan nyt uuden viestin, kun tuo edellinen oli enemmänkin vastaus Ganymedekselle.

Joku muukin on tuota lähiaikoina pohtinut ja kirjoittanut patchin, joka sittemmin on hylätty: http://lwn.net/Articles/497215/ Siellä on tultu tulokseen, että järjestelmiin joiden välillä tietoja jaetaan pitää tehdä yhteiset ryhmät. Tämä tietenkin vaatii sen, että kaikkiin järjestelmiin olisi pääsy, tai sitten Linux-jakelut ottaisivat käyttöön yhtäläiset ryhmätunnukset (gid) ja lisäisivät tuollaisen ryhmän oletuksena, mutta se lienee liikaa vaadittu ainakin tällä hetkellä. Tätä on jo mietitty ensimmäisessä viestissä. Tässä ei myöskään huomioida sitä ettei tiedostojärjestelmän päätasolle voi tehdä tiedostoja/hakemistoja ilman root-oikeuksia, mutta se on loppujen lopuksi aika pieni ongelma.

Niistä (hakemiston?) 777-oikeuksista vielä. Miten muuten käy jos tekee tiedoston, unohtaa asettaa sille oikeudet ja siirtää tikun toiseen järjestelmään. Ei liene oikeudet a=rw oletuksena, mutta onko ryhmä sama kuin hakemiston ryhmä? Tähän taisi olla joku tiedostojärjestelmän asetus, jota tune2fs voi säätää. Tällöin kuitenkin tuo ryhmäsysteemi olisi toimivampi kuin oikeuksien asettaminen 777:ksi. Tuohonhan vaikuttaa umask, voisiko sitä säätää tiedostojärjestelmään (liitosoptioissa ilmeisesti, mutta entäs pysyvämmin).

Lisäys eli tuommonen on mainittu tune2fs:n man-sivulla:

Koodia: [Valitse]

                  bsdgroups
                          Emulate  BSD  behavior when creating new files: they
                          will take the group-id of  the  directory  in  which
                          they  were  created.  The standard System V behavior
                          is the default, where newly created  files  take  on
                          the  fsgid of the current process, unless the direc‐
                          tory has the setgid bit set, in which case it  takes
                          the gid from the parent directory, and also gets the
                          setgid bit set if it is a directory itselfJa Linux.fi:ssä on tälläinen ohje, jossa on muita neuvoja tuohon jaettuun ryhmään: http://linux.fi/wiki/Kansion_yhteiskäyttö_ryhmässä

Noh, yritän nyt jotenkin pärjäillä tuon kanssa kunhan tikku siirtyy ihan oikeaan käyttöön. Ei ole vielä tänä viikonloppuna ehtinyt kuin teoriaa miettiä, niin paljon tärkeämpääkin tekemistä ollut.

[Ganymedes]

Joo, en tiedä mitä pitää tehdä. Kerroin vain tuntemiani ratkaisuvaihtoehtoja ja yleisiä perusteluja niille.

Jos kyse on vain tilapäisestä muutaman tiedoston vaihdosta erilaisten tuntemattomien järjestelmien välillä, mitä luettelit viimeksi, ilman tarvetta minkäänlaisille varmistuksille ja implisiittisesti ilman minkäänlaisia suorituskykyvaatimuksia, niin miksi sitten et käyttäisi tiedostojärjestelmiä jotka toimivat suoraan? Näitä ovat FAT32 ja NTFS.

Itse käytän FAT32:sta, toki fdiskillä alustettuna ja mkfs -komennolla luotuna välttääkseni epämääräisiä ongelmia tehdastikuissa. Tällöin tikku soveltuu suoraan myös telkkariin, multimedia-digiboksiin ja auton soittimeen.

FAT32:sta en käyttäisi varsinaisiin datajärjestelmiin tikulla, koska se on hyvin hidas suurella määrällä tiedostoja - mutta sellaista tarvettahan sinulla nyt sitten ei ollut.

[Tomin]

FAT32:sta en käyttäisi varsinaisiin datajärjestelmiin tikulla, koska se on hyvin hidas suurella määrällä tiedostoja - mutta sellaista tarvettahan sinulla nyt sitten ei ollut.

Juu, kyse onkin enemmän periaatteellisesta asiasta.

Tätä asiaa olisi varmaan muutenkin ihan hyvä miettiä, jos haluaa että tikuilla käytettäisiin muutakin kuin Microsoftin FAT:ia.

Käytännössä FAT tuskin häviää minunkaan käytöstä mihinkään, vaikka se vajavainen onkin (esimerkiksi 4 gigan tiedoston kokorajoitus, joka on tässä käytössä puutteista suurin).

[Ganymedes]

FAT32:sta en käyttäisi varsinaisiin datajärjestelmiin tikulla, koska se on hyvin hidas suurella määrällä tiedostoja - mutta sellaista tarvettahan sinulla nyt sitten ei ollut.

Juu, kyse onkin enemmän periaatteellisesta asiasta.

Tätä asiaa olisi varmaan muutenkin ihan hyvä miettiä, jos haluaa että tikuilla käytettäisiin muutakin kuin Microsoftin FAT:ia.

Käytännössä FAT tuskin häviää minunkaan käytöstä mihinkään, vaikka se vajavainen onkin (esimerkiksi 4 gigan tiedoston kokorajoitus, joka on tässä käytössä puutteista suurin).

Kyllä, tässä on periaatteellinen ongelma, joka on edellä hyvin tullut ilmi näiden rajoitusten kanssa. FAT32:n suorituskyky ja NTFS:n korjausmahdollisuuksien puute, jotka on edellä jo mainittu. Ei tule mieleen muita vaihtoehtoja kuin keskusteltu 777-menetelmä ... tosin itse olen ratkaissut asian sillä, että tarpeen mukaan USB-medioita on useammanlaisia - halpojahan ovat.

[SuperOscar]

Niistä (hakemiston?) 777-oikeuksista vielä. Miten muuten käy jos tekee tiedoston, unohtaa asettaa sille oikeudet ja siirtää tikun toiseen järjestelmään.

Ks. yllä tarinani Tampereen yliopistosta. Järjestelmä ei tosin ollut Linux vaan Solaris, mutta jatkuvaa harmia seurasi.

Lisäys eli tuommonen on mainittu tune2fs:n man-sivulla:

Suhtaudun setgid-bitteihinkin epäluuloisesti. Olen yleensä yrittänyt antaa erilaisille siirtokansioille oikeudet 6770, mutta se pelaa vain osittain. Esimerkki-istunto:

Koodia: [Valitse]

tn@bahtin [~/Tilap/foo]$ md spam; chmod 6770 spam; dir
yhteensä 0
drwsrws--- 2 tn tn 6 2012-11-11 19:55 spam/
tn@bahtin [~/Tilap/foo]$ cd spam; touch eggs; dir
yhteensä 0
-rw------- 1 tn tn 0 2012-11-11 19:55 eggs
tn@bahtin [Tilap/foo/spam]$ cd ..; chgrp -R porukka spam; dir
yhteensä 0
drwxrwx--- 2 tn porukka 17 2012-11-11 19:55 spam/
tn@bahtin [~/Tilap/foo]$ cd spam; touch more_spam; dir
yhteensä 0
-rw------- 1 tn porukka 0 2012-11-11 19:55 eggs
-rw------- 1 tn tn      0 2012-11-11 19:56 more_spam
Toisin sanoen 6770 varjelee vain sitä, että tiedoston omistajaksi tulee ryhmä, joka omistaa kansion; se EI varjele sitä, että g+rw säilyisi, jos umask (minulla 077) sen estää.

Käytännössä siis käyttäjän pitäisi aina muistaa antaa chmod lopuksi, mutta arvatkaapa vain, muistaisinko itsekään? 

Sikäli siis kuin tiedän:

• et selviä ilman jotakin nimellistä välikansiotasoa tikulla
• ja sittenkin olet aika lailla umaskin armoilla sen suhteen, mitkä oikeudet tikulle kirjoitettaviin tiedostoihin tulee

Ja kyllä, minäkin koen tämän ongelmaksi. En niinkään pakollisen välitason takia vaan siksi, että koskaan ei voi olla varma, että tikun tiedostot saa luetuksi siirryttäessä toiselle koneelle. UNIXin tiedostomääritteet luotiin selvästi aikana ennen siirrettäviä tietovälineitä...

[Tomin]

UNIXin tiedostomääritteet luotiin selvästi aikana ennen siirrettäviä tietovälineitä...

Sen kyllä huomaa. Jääköhän tuo puute korjaamatta, kun pilvipalvelut ja nopeat nettiyhteydet lisääntyvät. Toisaalta olisi kiva korjata moinen puute, jotenkin...

[Postimies]

FAT tiedostojärjestelmä tehtiin aikoinaan levykkeille. Harva enää muistaa tai on kokenut DOS:sin tiedostonimien rajoitukset 8+3 merkkiä ja piste siinä välissä. Tiedostojen kokorajoitus ei ollut ongelma. Levykkeen koko oli niin pieni. Kun tuli ensimmäiset kovalevyt, niin niissä aloitettiin käyttämään olemassa olevaa FAT-systeemiä. Koko ei ollut ongelma vaan Mikrosoftin buginen fdisk, joka salli aikoinaan vain 32 megasen osion teon. Vai oliko se 31 megaa... Kun Mikrosoft sitten korjaili systeemiään päästiin tekemään jo hieman isompia levyosioita. Mutta aina oli jotain pielessä. Aina!. Eihän XP osannut osioida isoa levyä. Vista taisi olla ensimmäinen jolla uskalsi ottaa vaikka 500G levyn käyttöön yhtenä osiona. Ja oli tuki myös isoille tiedostoille..

FAT lienee lisenssivapaa. En muista kuka on kehittänyt. Mikrosoft varmaan osti tai varasti jostain kuten koko DOS-systeemin aikoinaan. Jostain syystä tuota pirun FAT-tiedostojärjestelmää käytetään vieläkin. Pienillä tiedostomäärillä ei mitään ongelmaa. Jos paljon tiedostoja luku on hidasta linkitetystä listasta jos verrataan hakua binääripuusta. Tämä korostuu hitaalla laitteella.  Tiedostojen koko ongelmaa voi kiertää jakamalla tiedoston esim. moneen rar-pakettiin. Esim. 8G teräväpiirtö videon kirjoittaminen fat tikulle on tuskallista.  Itse käytän  rar a -v100000k ...  ja menen keitämään kahfia ym..

Harvalla tutulla eikä töissäkään ole Linux konetta joten en näe järkeä ext3 tai ext4 tikun teolle. Käynnistyvät tikut ovat tietysti eri asia. Pieni Linux tikulla & XBMC on ihan kiva median toistamiseen. Tällöin on ext2 tai vastaa hyvä. Ulkoisilla kovalevyillä sitten taas ext4 alkaa olla välttämättömyys. Vaikka siirrettävyys Windows koneisiin menetettäisiinkin.

[Tomin]

FAT lienee lisenssivapaa.

Alkuperäinen ehkä, pitkistä tiedostonimistä käytiin muistaakseni äskettäin oikeudessa, joka kuitenkin käsittääkseni kääntyi Microsoftin häviöksi ja Torvaldskin oli todistamassa.

Tiedostojen koko ongelmaa voi kiertää jakamalla tiedoston esim. moneen rar-pakettiin. Esim. 8G teräväpiirtö videon kirjoittaminen fat tikulle on tuskallista.  Itse käytän  rar a -v100000k ...  ja menen keitämään kahfia ym..

Kannattaako pakattua videota pakata? (tosin koska en käytä niin voi olla ettei pakkaa, itse tietänet paremmin)
Mutta toinen juttu tuohon liittyen, rar:iin muistaakseni liittyy patentteja (tjms.), joiden vuoksi sitä ei voi jaella ihan vapaasti ja siksi vältän sen käyttöä (siis en ainakaan kannusta muita käyttämään, joskus pitää jotain purkaa kuitenkin).

[SuperOscar]

Kannattaako pakattua videota pakata?

Yleensä ei. Minä käytän split-komentoa, joka yksinkertaisesti vain jakaa tiedoston osiin.  Lisäetuna on, että tiedoston voi kasata entiselleen rajoitetuimmissakin järjestelmissä, koska palaset yksinkertaisesti liitetään yhteen (cat-komennolla).

Tuota tulee tehdyksi silloin tällöin, koska kätevin iso irtokiintolevyni (= ainoa joka ottaa virran USB-liittimestä) on matkakäyttöä ajatellen VFAT-alustettu ja siis totta kai rupeaa urputtamaan yli kolmigigaisista tiedostoista. Aika tuskallisen moni elokuvatallenne ylittää rajan.

Postimiehen muisteloihin:

Mutta aina oli jotain pielessä. Aina!. Eihän XP osannut osioida isoa levyä. Vista taisi olla ensimmäinen jolla uskalsi ottaa vaikka 500G levyn käyttöön yhtenä osiona. Ja oli tuki myös isoille tiedostoille..

Mitä ihmettä? Kyllä NTFS oli oletustiedostojärjestelmä jo XP:ssä. Ei ollut ongelmia isojenkaan levyjen käyttöönotoissa eikä isojen tiedostojen tallentamisessa niille. 9x-aikana oli toisin – mutteipa silloin vielä 500-gigaisia levyjäkään ollut, saati yleisessä käytössä isoja tiedostoja.

[mrl586]

Niistä (hakemiston?) 777-oikeuksista vielä. Miten muuten käy jos tekee tiedoston, unohtaa asettaa sille oikeudet ja siirtää tikun toiseen järjestelmään.

Ks. yllä tarinani Tampereen yliopistosta. Järjestelmä ei tosin ollut Linux vaan Solaris, mutta jatkuvaa harmia seurasi.

Tarkoitatko järjestelmällä kieloa?