Ideální souborový systém (diskuse)

[Luk]

Metadata: Stačí, aby souborový systém implementoval rozšířené atributy. Totéž se týká i ACL (v Linuxu se implementuje přes atributy system).

[Miloslav Ponkrác]

Možná budu vypadat jako kverulant, ale já mám ještě navíc požadavek, že názvy souborů a adresářů se budou brát a implicitně předpokládat jako Unicode.

Jinak řada Vašich požadavků jde dost proti sobě.

[xkucf03]

1) To je dobrá připomínka, dobré kódování beru jako samozřejmost, takže jsem na něj asi zapomněl. (jistě jsi myslel kódování utf-8 případně 16, nikoli unicode, že?)

2) Co konkrétně jde proti sobě? Napadá mě leda "duplicitní" funkcionalita u "Možnost zvětšování a zmenšování oddílu" a "Kvóty pro složky" - na druhou stranu je normální, že k jednomu cíli vede více cest.

[alblaho]

Tečková konvence pro skryté soubory má sice tu nevýhodu, že nelze jen tak skrýt existující (pojmenovaný) soubor, ale jinak to funguje velice dobře. Je to "convention over configuration". Ale asi by se ten atribut občas hodil.

Zato indexování na úrovni FS je IMO blbost. Protože pak by musel FS data interpretovat (jak vypadá text, jak vypadá mezera, používá se utf8, jaké je locale). Tohle prostě do vrstvy ukládání dat nepatří. Ale nějaká metadata na úrovni FS jako jazyk a kódování, to by se hodit mohlo.

[Luk]

indexování na úrovni FS je IMO blbost. Protože pak by musel FS data interpretovat (jak vypadá text, jak vypadá mezera, používá se utf8, jaké je locale). Tohle prostě do vrstvy ukládání dat nepatří.

Tohle pochopili i u Microsoftu a proto je jejich (zatím nedokončený) WinFS vytvořen jako samostatná vrstva nad NTFS.

Ale nějaká metadata na úrovni FS jako jazyk a kódování, to by se hodit mohlo.

Proč znovu objevovat kolo?

[Michal]

Me by se libilo, kdyby disky v systemu tvorily jeden pool diskove kapacity s moznosti pridavat/odebirat disky. Na nem by se vytvarely oddily, ktere by sdilely volnou kapacitu poolu.

smartd: na WD3200JS-00PDB0 povazlive roste Reallocated Sector Count, asi pujde do kytek
ja: zatrsakr prace!
ja: fs -removedisk WD3200JS-00PDB1
fs: to nejde vole, schazelo by 30GB mista
ja: rm ~/porn
ja: s -removedisk WD3200JS-00PDB0
fs: provadim, ETA: 2h 30min, pool a vsechny oddily jsou stale read-write, muzes pokracoat v praci vole, akorat pamatuj, ze pool je nyni mensi o kapacitu WD3200JS-00PDB0. Behem provadeni operace je povoleno restartovat pocitac potazmo vypnout ho.
ja: pelasim do kramu pro disk, hotpluguju ho
ja: fs- adddisk ID
fs: disk pridan. kdybys nebyl zbrkly a pripojil jsi ten novy disk pred tou operaci removedisk tak jsi nemusel mazat to pornicko
ja: zatrsakr prace!

tak, a ted mi todle nekdo naprogramujte!

[otula]

Nějak mi to připomíná LVM…

[Michal]

Ale kdeze. LVM poskytuje jen tu nejtrivialnejsi vec z pozadovanych- vytvoreni poolu z dostupnych disku. Oddily sdilejici volnou kapacitu poolu uz jdou mimo ramec LVM, o tom, ze by se dalo z poolu odebrat disk s daty (tak, ze se to samo postara o presun dat na jine disky v poolu samozrejme) si muze nechat jen zdat.

ZFS by to dokazal ale ten jen tak v linuxu nebude :(

[Sinuhet]

A znate prikaz pvmove?

[Michal]

Znam. Je ale zbytecne se o tom bavit, neni splnena zakladni pozadovana vlastnost- sdileni volneho prostoru v oddilech tzn. ze "logical volumes" musi byt na "physical volumes" nutne rozkouzkovana a promichana. To prenasi problem presunuti dat z jednoho disku na jine do zcela jineho rozmeru. Zakladni problem LVM v teto aplikace je ten, ze nevi nic o tom, co je v nem ulozneo, nerozumi souborovym systemum. Tohle neni chyba, proste tento system nebyl pro takove ucely urcen.

[michich]

neni splnena zakladni pozadovana vlastnost- sdileni volneho prostoru v oddilech

Můžeš tuhle vlastnost nějak blíže specifikovat? Pořád nevím, co tím myslíš.

To prenasi problem presunuti dat z jednoho disku na jine do zcela jineho rozmeru.

Prostě zavolám pvmove /dev/disk_který_chci_přestat_používat. Kde je jaký jiný rozměr?

[Michal]

Ano, popisu. Mam dva 500GB disky. Vytvorim na nich 1000GB pool. Na nem vytvorim oddil A a oddil B. Na oddilu A je 1000GB mista, na oddilu B je 1000GB mista. Na oddil A nahraju 100GB dat. Na oddilu A je 900GB volneho mista a na oddilu B je take 900GB mista. Tohle je sdileni mista, velmi uzitecna vec.

[michich]

Proč potom prostě nemít jeden oddíl a na něm dva adresáře?

[Heron]

No a jaký má smysl to dělit do oddílů, když ti tohle v podstatě zaručí rozdělení do adresářů?

[Michal]

Ma protoze nad oddilem jde udelat snapshot. Lze mu nastavit separatne kvoty. Lze ho migrovat z jednoho poolu na druhy (pozor kopirovani adresare je menecenne- nad kopirovanymi daty se neda pracovat). Lze nastavit maximalni velikost je li to vhodne. Jde ho odmountovat. Je to lepe spravovatelne. Musim pokracovat? :)

[michich]

OK. Do jisté míry jde ono sdílení volného místa udělat s LVM tak, že logické oddíly nevytvářím přehnaně velké, aby mi ve volume groupě zbylo nealokované místo. Až když vidím, že na některém oddílu by bylo potřeba místa víc, zvětším ho. Zmenšování je složitější, ale to jsem ještě nikdy nepotřeboval

[Luk]

rm ~/porn

Aneb jak nejrychleji získat 50 GB volného místa

[Jardík]

To těžko. Akorát by se zobrazilo, že ~/porn je adresář

[nolly]

Třeba je to jedno velké 50GB video, které vzniklo slepením spousty klipů :)

[Luk]

No jo. Chtělo by to přidat -r a ještě líp -rf. Nevšiml jsem si těch chybějících parametrů - to bude asi tím, že obvykle mažu přes mc

[Heron]

Přes víkend jsem si hrál s sw raidem a lvm a dělal jsem přesně tohle. Další splněný úkol .

[rADOn]

skryvaci atribut je s prominutim pitomost. pokud chci aby nekdo neco nevidel, seberu mu prava. cokoliv slozitejsiho jen vzbuzuje falesny pocit bezpeci. *nixova teckovaci konvence je mozna trochu divna ale funguje lip nez cokoliv jineho. kdyz to bude nejaky atribut bude potreba zase dalsi syscall a spousta logiky ve vsech programech ktery by to chtely pouzit - proc vlastne ? aby umel neco co doted slo resit jednoduseji. ano je hezky ze by slo menit atribut aniz by si toho program vsiml, ale to taky znamena ze vsechny programy ktery si toho naopak vsimnout maji by mely praci navic. archivace, kopirovani, dokonce i prilozeni k emailu by se s tim muselo nejak poprat. co treba presmerovani / pipovani ? ve spravnym unixu se staci podivat na masku prav procesu a cas a muzes sypat cokoliv kamkoliv. kdyz budou mit soubory dalsi atributy uz musis resit co s nimi. potichu zkopirovat ? zahodit ? vzit nejaky default ? pridat dalsi syscall kterym se to bude ridit ?

nic z toho nebude ve vysledku lepsi nez tecka - a vsechno to bude podstatne slozitejsi.

[xkucf03]

falesny pocit bezpeci

Skrývání souborů nemá vůbec nic co do činění s bezečností. Týká se primárně uživatelského rozhraní. Uživatel si skryje složky a soubory, které nepoužívá, aby se mu nepletly mezi ty používané a měl svoje adresáře přehlednější.

Používání tečky pro skrývání je chyba návrhu a její obhajování je pouze z nouze ctnost. Lepší by bylo, nechat na uživateli, zda chce mít konkrétní soubor/adresář skrytý nebo ne. Jden uživatel třeba rád chodí do složky ~/.fooBar a druhý ani neví, že ji tam má. Uživatelé mají různé potřeby a software by to měl respektovat. Ona skrývací tečka je nešťastné dědictví z doby, kdy se UI a desktopu nepřikládal takový význam a důležité byly jiné věci.

[Luk]

Týká se primárně uživatelského rozhraní. Uživatel si skryje složky a soubory, které nepoužívá, aby se mu nepletly mezi ty používané a měl svoje adresáře přehlednější.

Lepší řešení (čistší a flexibilnější), než se vrtat ve vnitřnostech metadat FS, by bylo definovat si rozšířený atribut, například něco jako user.visibility = "hidden" a všechny soubory s touto hodnotou vyřadit ze zobrazování.

[xkucf03]

Tak nějak bych si to představoval, je v podstatě jedno*, jestli na to bude zvláštní atribut nebo to bude mezi ostatními metadaty (uvítal bych datový typ boolean místo nějakého řetězce "hidden"). Jde jen o to, aby to podporovaly správci souborů (v KDE, GNOME atd.) a příkazy jako ls.

*) i když tenhle atribut bude dost často používaný, tak by se to dalo nějak optimalizovat, aby k němu byl rychlejší přístup než k ostatním metadatům.

[Luk]

uvítal bych datový typ boolean místo nějakého řetězce "hidden"

Může být. Uváděl jsem to jen jako příklad.

i když tenhle atribut bude dost často používaný, tak by se to dalo nějak optimalizovat, aby k němu byl rychlejší přístup než k ostatním metadatům

No, ono to rychlejší/pomalejší je tady hodně zajímavé. Pokud se musí sáhnout na disk (přečíst to z disku), bude to pomalé tak jako tak. A v opačném případě záleží na tom, jestli se bude číst jen ten jeden atribut nebo i další metadata. Totiž volání stat() je samo o sobě dost pomalé, provádí totiž trojité kopírování.

Na druhou stranu getxattr() vyhodnocuje název atributu, a to tak (v generické implementaci), že prochází celý seznam a porovnává řetězce s názvem. Pro malý počet to není problém, ale když si nějaký vtipálek vytvoří spoustu atributů (pokud mu to FS dovolí), lineární složitost už bude na rychlosti znát.

[rADOn]

... zatimco tecka je videt uz pri cteni nazvu inode, tedy teoreticky zadarmo. prakticky i levneji nez zadarmo protoze spousta softu hleda tecku aby vynechala odkazy na aktualni a nadrazeny adresar a 'skryte' soubory se jen vezou. nejspis tak ta konvence i vznikla.

Ja si nemuzu pomoct ale to co tady resite mi pripada jako widlema vypestovana podvedoma touha opatrovat veci cudlikama a ikonkama. Ja jsem taky odkojenej na DOSu ale nektery veci mi proste nechybi. Ptam se znovu - co se stane kdyz soubor se skrytym atributem pridate jako prilohu k emailu ? budete menit RFC822 ? obalovat to tarem ? pridavat vlastni X- hlavicky ? nebo ten atribut zahodite cimz dostanete _horsi_ funkcnost nez je ted ?

[Luk]

Ja si nemuzu pomoct ale to co tady resite mi pripada jako widlema vypestovana podvedoma touha opatrovat veci cudlikama a ikonkama.

Já jsem s tím nezačal. Jen říkám, že když už to tam někdo chce mít, ať použije rozšířené atributy, protože ty už tam (v jádře a některých FS) jsou implementovány. I když, s těmi ikonkami to není špatný nápad Třeba něco jako user.icon_mime_type = image/svg+xml, user.icon_storage_type = inline, user.icon_data = <?xml version="1.0"?><svg xmlns="http://www.w3.org/2000/svg"...

Ptam se znovu - co se stane kdyz soubor se skrytym atributem pridate jako prilohu k emailu ?

Nic. Bude se chovat jako jakýkoli jiný soubor. Podobně, jako se v takovém případě neuchovávají přístupová práva nebo časové údaje. Čili:

nebo ten atribut zahodite cimz dostanete _horsi_ funkcnost nez je ted ?

[happy barney]

takto?

user.1.visibility = "visible"
user.1001.visibility = "hidden"
user.1002.visibility = "visible"

blbosť. Ako poznamenal rADOn, toto majú riešiť práva (ACL).

[xkucf03]

1. Skrytost se týká GUI, jde o pohodlí uživatele a přehlednost adresářů. Nemá sloužit pro zabezpečení (ani před dětmi).
2. Aby si každý uživatel mohl ovlivnit viditelnost každého souboru je asi příliš velký luxus. IMHO je dostačující, když viditelnost souboru bude společná pro všechny uživatele a určí ji vlastník souboru.
3. Je otázka, jestli to řešit jedním atributem-bitem, nebo metadaty. Načtení bitu by mělo být rychlejší, na druhou stranu řešení pomocí metadat je systémovější, chtělo by to testy výkonnosti.

[happy barney]

1+2 => man chmod

[Filip Jirsák]

Skrytost se týká GUI, jde o pohodlí uživatele a přehlednost adresářů.

Opravdu si nemyslím, že by se přehlednost vytvářela tím, že se nepořádek zakryje. Pořád mi připadá jako daleko lepší uklidit (uspořádat adresářovou strukturu). Mám pocit, že jste jediný, kdo svůj nepořádek v adresářích veřejně prezentuje a požaduje kvůli němu hack do jádra.

[xkucf03]

Kdybys četl moje příspěvky pořádně, tak bys lépe chápal moji motivaci a neosočoval mě z bordelářství:

1. Skrývání pomcí tečky považuji za nesystémové řešení, chybu návrhu, bast, z nouze ctnost... I tak primitivní souborový systém jako je FAT32 problém řeší lépe a stačí mu na to jediný bit. Skrývání tečkou není tragédie, dá se s tím žít, ale každý rozumně uvažující člověk se přinejmenším pozastaví nad tím: proč by se proboha měla měnit cesta k souboru (jméno), když chci změnit jeho skrytost/neskrytost?
2. Jako příklad jsem použil jeden nedokonalý program, který pojmenovává svoje soubory trochu jinak, než bych si představoval. Uplatnění se najdou i jinde... Kdybychom předpokládali, že všechny programy jsou dokonalé, tak bychom mohli klidně všechno pouštět pod rootem, včetně KDE, webových serverů, databází... ale protože nejsou, musí být v OS prostředky, jak tyto nedokonalosti vyřešit.
3. Jsem přesvědčený, že vliv (kvalitní) implementace skrývání pomocí atributu (případně metadat) na rychlost bude pro uživatele nepostřehnutelný a přitom to bude pro uživatele užitečné.

Odmítám dělat z Unixu/Linuxu nějakou posvátnou krávu a oslavovat tečkovou konvenci jako nějaké geniální řešení, když ji považuji za bastl.

[Filip Jirsák]

Pořád dokola – tečka není určena ke skrývání, ta implikace je opačná. FAT32 problém skrývání řeší, a ten atribut se dnes prakticky nepoužívá. Osobně si myslím, že atribut pro skrývání souborů je zbytečný, a je nás asi (významná) většina. Uživatelů, kteří by potřebovali skrývání souborů, je asi velmi málo – nicméně nic vám nebrání vybrat si nějaký pěkný název EA a naprogramovat třeba do Qt dialogů a KDE aplikací skrývání souborů podle toho EA.

[Miloslav Ponkrác]

Atribut skrývání souborů se ve FAT32 tvrdě používá. Ve Windows je implementovaný a prakticky všechno zobrazování souborů implicitně tyto soubory nezobrazí, pokud si nenastavíte jinak. Stejně tak všechny dialogy pro otevření souboru atd.. Řada souborů ve Windows tento atribut nastavený má.

Mě se moc líbí, když někdo snese lživý argument a postaví na něm obhajobu svého názoru.

Atribut pro skrývání souborů rozhodně zbytečný není, je to super věc - prostě to běžného uživatele neláká otevírat, měnit a vůbec hrát si se soubory, kde by nadělal škodu. Ani ho to nepokouší. Souborové dialogy, stejně tak jako různé NC like commandery prostě ukazují pouze soubory, které nejsou až tak kritické.

Samozřejmě, že každý program nepoužívá skrývání na 100%, nic není zcela dokonalé, ale i tak je to príma.

[Filip Jirsák]

Atribut skrývání souborů se ve FAT32 tvrdě používá. Ve Windows je implementovaný a prakticky všechno zobrazování souborů implicitně tyto soubory nezobrazí, pokud si nenastavíte jinak. Stejně tak všechny dialogy pro otevření souboru atd.. Řada souborů ve Windows tento atribut nastavený má.

Nepoužívá. Ona volba pro skrývání souborů se totiž jmenuje „skrývat skryté a systémové soubory“, a všechny soubory, které jsou tímto způsobem skryté, jsou systémové. Pokud mají zároveň nastaven příznak skrytý, je to pouze historický relikt – kdybyste ty soubory označil pouze příznakem systémový, bude se to chovat naprosto stejně.

A jak se v linuxu označují systémové soubory? Tečkou na začátku. Vadí to něčemu? Nevadí, protože systémové soubory mají v drtivé většině případů pevně danou cestu, takže je nesmysl pokoušet se je přejmenovávat; zároveň jsou ty soubory systémové po celou dobu své existence a nemá tudíž smysl souboru příznak systémový přidávat nebo odebírat.

Mě se moc líbí, když někdo snese lživý argument a postaví na něm obhajobu svého názoru.

Ten argument nebyl lživý. Pouze jsem neskončil u toho, abych se podíval na dialog Vlastnosti souboru, uviděl „skrytý“ a usoudil z toho, že se ten atribut používá – místo toho jsem pátral po tom, zda a jak se skutečně používá.

To co popisujete dál je sice hezké, ale to co popisujete nejsou primárně skryté soubory, ale jsou to systémové soubory – které se následně nezobrazují, takže se to navenek projevuje stejně, jako by byly skryté.

[Filip Jirsák]

Uživatel si skryje složky a soubory, které nepoužívá, aby se mu nepletly mezi ty používané a měl svoje adresáře přehlednější.

Pochybuji o tom, že nějaký program používá pro svou konfiguraci nějaké adresáře nebo soubory bez tečky v ~/. Takže zbývá vyřešit dvě věci – aby uživatel neměl hned na ráně svoje adresáře, které nepoužívá často. To se vyřeší tím, že bude mít ve svém home nějakou rozumnou adresářovou strukturu, ne smetiště. No a druhá věc je, pokud uživatel často potřebuje nějaké skryté soubory či adresáře. A to vyřeší odkazy.

[Zdenek.Z]

Pochybuji o tom, že nějaký program používá pro svou konfiguraci nějaké adresáře nebo soubory bez tečky v ~/

Třeba WindowMaker má konfiguraci v ~/GNUStep/. GNOME a KDE si zase dělají ~/Desktop/ (možná to jde změnit). A rozumnou adresářovou strukturu mít uživatel může a přesto třeba bude chtít po nějakou dobu využívat především adresáře ~/[XYZ], tak si ostatní skryje. Ne že bych já takovou potřebu měl, ale co je na tom nepochopitelného?

[Filip Jirsák]

WindowMaker by zasloužil opravit, Desktop je asi brán jako standardní uživatelův adresář.Pokud budu chtít pracovat jen s určitou množinou adresářů, udělám si nějaký adresář v home a do něj si dám linky. Rozhodně nebudu šachovat s viditelností souborů, protože to je věc celého systému, ale práce s určitou množinou adresářů bude nejspíš omezená na určitý program nebo typ úlohy (takže když budu pracovat s fotkama v Gimpu, nebudu si vše ostatní skrývat, abych vzápětí zjistil, že se potřebuju mrknout do jednoho dokumentu, který jsem si právě skryl).

[xkucf03]

Ne že by to něšlo Ale snad uznáš, že je to nouzovka, náhradní řešení, které se používá, protožeto jinak nejde. Připadá mi to jako říct: "nepotřebujeme obrázky na webu, použijeme ascii-art, stejně jen zbytečně zatěžují Síť." Z pohledu uživatele je úplně přirozené, že skrytost je vlastnost souboru a nijak nesouvisí s jeho názvem - proto OS, které kladou větší důraz na desktop to mají implementované jako atribut. IMHO by měl být na prvním místě uživate a SW by měl respektovat jeho potřeby a nenutit ho měnit jeho chování jen proto, že to kdysi někdo nějak implementoval a teď se to nechce nikomu předělávat.

Líbilo by se mi tohle řešení:

• Zapouzdření funkcionality do vrstvy, která by rozhodovala buď na základě tečky na začátku, metadat, nebo atributu (zvláštní bit)
• Uživatel by si mohl vybrat způsob, jakým se má rozhodovat o skrytosti souborů.
• Uživatel by si mohl vybrat, jestli to chce jen v GUI (a v konsoli používat starý způsob s tečkou) nebo v GUI i v konsoli

Ten, kdo se bojí o výkon, třeba na serveru, tak by používal starý způsob s tečkou, zatímco desktopoví uživatelé budou mít víc pohodlí. A budou všichni spokojeni, teď už zbýva jen, aby to někdo napsal

[Filip Jirsák]

Ne, pro mne to nouzovka není. Když pracuju na klasickém pracovním stole, vytáhnu si jenom tu složku papírů nebo knihu, kterou budu potřebovat, a pak jí zase uklidím. Nedělám to tak, že bych měl na stole haldu všeho možného, a podle potřeby něčím zakrýval to, s čím zrovna nepracuju.

Já nechápu „skrytost“ souboru jako nástroj pro GUI, je to něco podobného, jako v DOSu systémový soubor. OS, které kladou větší důraz na desktop a mají skrytost implementovánu jako atribut vůbec nepředpokládají, že by skrytí uživatel používal jako nějaký dočasný filtr pro GUI – odkrytí takového souboru (bavíme-li se o Windows) totiž znamená docela náročnou operaci s přepínaním nastasvení složky kdesi ve stromovém menu, uživatel musí vědět přesně kde to má hledat a jestli to udělá na 20 kliknutí, je to celkem slušný výkon. Takže zrivna v těch Windows znamená atribut „skrytý“ soubor, který by běžný uživatel neměl nikdy vidět a nepotřebuje vůbec vědět, že nějaký takový soubor existuje.

[xkucf03]

Nejde přece o to, že by uživatel si skrýval soubory na základě aktuálních potřeb a pořád to měnil sem tam. Jde o to, že různí uživatelé mají různé potřeby skrývat/odkrývat soubory - a z toho vyplývá zcela přirozený požadavek, že o skrytosti/neskrytosti by si by měl rozhodovat uživatel, nikoli programátor aplikace (tím, jestli sobubory pojmenuje s tečkou na začátku).

Příklad z Windows: Ovladač PDF tiskárny mi vytvoří v dokumentech složku "PDF files" Protože do ní bežně nechodím, skryju si ji a mám ji pořád skrytou, abych měl to měl přehlednější.

Příklad z Linuxu: v domácím adresáři mi straší několik souborů a složek, které nikdy nepoužívám (ale používám aplikace, které je vytvořily, takže se jich nemůžu zbavit). A nemám jedinou možnost, jak si je skrýt, leda že bych si překompilovat dané programy, aby ty soubory hledaly jinde.

[Filip Jirsák]

To je pak potřeba opravit ty aplikace, aby umožňovaly nastavit umístění adresáře. Vytvořím si v home složku „smetí různých aplikací“, a tam ať mi ta aplikace ty dokumenty PDF generuje. Berte to tak, že běžný uživatel by neměl nikdy mít potřebu otvírat nějaké skryté adresáře nebo soubory (pokud nechce ručně něco konfigurovat). Vy ty vygenerované dokumenty PDF asi k něčemu chcete, takže ten adresář nechcete skrýt, ale jenom uklidit někam, kde nebude moc překážet.

[xkucf03]

To je pak potřeba opravit ty aplikace, aby umožňovaly nastavit umístění adresáře.

1. Jak přimět autory všech aplikací, aby je upravili? Mnohem přijatelnější mi přijde upravit KDE/GNOME (a další) aby braly v úvahu i jiné způsoby skrývání, než je tečka. A postupně tuhle vymoženost dostat i do konsolových nástrojů.
2. Jak bude aplikace vědět, kde má soubor hledat? Musí si to někam uložit, třeba do ~/.aplikace a v tom případě jsme se nepohnuli ani o kousek dál. Každé nastavení je prostě potřeba někam uložit. A nejde jen změnit cestu k adresáři s nastavením, protože aplikace by nevěděla, kde ho hledat - to bychom ji museli překompilovat, použít něco jako registr z Windows, nebo změnit nastavení pro celý systém, což ale neřeší problém s tím, že různí uživatelé mají různé potřeby.

Můžeme říct: snížilo by to výkon a dalo by to moc práce, proto nebudeme skrývat pomocí metadat. Tak to bych ještě bral. Ale snažit se tvrdit, že to vlastně nikdo nepotřebuje mi přijde hloupé. Protože výrok: různí uživatelé mají různé potřeby skrývání/odkrývání souborů, považuji za nepopiratelný. A z něho pak vyplývá, že by si tuto vlastnost měl řídit uživatel, nikoli programátor aplikace.

[Filip Jirsák]

Pokud je chyba v aplikaci, je lepší opravit aplikaci, než vymýšlet x obezliček, jak chybu obejít. Pokud aplikace ukládá uživatelské dokumenty nebo data někem jinam, než chce uživatel, je to chyba.

Konfigurační soubor má být s tečkou (nebo v adresáři s tečkou), protože je to věc, se kterou běžný uživatel nepotřebuje přijít do styku. A uživatel nepotřebuje tenhle soubor/nebo adresář) skrývat a odkrývat. Pokud jo někdo touží po tom ten soubor neustále editovat ručně, nic mu nebrání udělat si na něj link bez tečky.

Výrok různí různí uživatelé mají různé potřeby skrývání/odkrývání souborů vůbec neřeší, k čemu je skrývání a odkrývání souborů dobré. V současné době to funguje tak, že soubory s tečkou jsou brány jako systémové soubory, se kterými uživatel běžně nepotřebuje pracovat přímo. Které soubory to jsou ví programátor aplikace celkem dobře – jsou to konfigurační a pomocné soubory (na rozdíl od dokumentů, se kterými uživatel naopak pracovat potřebuje). Jak vyřešit, pokud nějaký uživatel potřebuje často přistupovat k systémovému souboru už jsem napsal. Takže zbývají dvě otázky – potřebuje uživatel přistupovat k systémovým souborům tak často, aby si nemohl vypomoci linkem? A pak zbývá ještě problém skrytí souboru, tedy otázka, kdy potřebuje nějaký soubor uživatel označit za systémový? Moje odpovědi na ty dvě otázky jsou „výjimečně“ a „nikdy“.

[xkucf03]

Pokud je chyba v aplikaci...

Kdo říká, že je chyba v aplikaci? Vezměme si jako příklad tu PDF tiskárnu: programátor nemůže vědět, jestli uživatel tu složku "PDF files" bude používat nebo ne. Proto je zcela správné, že o jejím skrytí/neskrytí rozhodne uživatel.

Narozdíl od jiných uživatelů Linuxu, ho používám jako hlavní (a téměř jediný) desktop, možná i proto mi vadí i relativně maličkosti tohoto typu. I když mi Linux/Unix vyhovuje ze všech OS asi nejvíc, tak musím říct, že některé věci (zas tak moc jich není) jsou ve světě Windows řešeny lépe.

Pokud se neshodneme na platnosti výroku různí uživatelé mají různé potřeby skrývání/odkrývání souborů bez ohledu na důvod skrývání, tak nemá cenu pokračovat v diskusi v tomto vlákně.

Pokud se na problém podíváme očima databázisty, tak:

• soubor = entita
• cesta k souboru = jeden atribut
• skrytost = druhý atribut

A jistě by nebylo správné navrhnout DB tak, aby změna jednoho atributu vyvolala změnu jiného atributu, který s se změnou vůbec nesouvisí.

Je to něco, jako kdybychom do předmětu e-mailu namastili datum odeslání, třeba to hranatých závorek. Sice by to možná nějak fungovalo, ale je to prasárna. Místo toho máme v hlavičce zprávy zvlášní položku pro datum. A tak je to správně, tak to má být

[Filip Jirsák]

Pokud programátor nemůže vědět, zda uživatel bude tu složku používat, nebo nebude, má k tomu dát volbu do konfigurace, kde se ta možnost jednak zapne, jednak se nastaví cesta. Jinak je to chyba (nedomyšlenost) programu.

Pokud uživatelé nemají potřebu měnit nastavení „skrytosti“ souboru (jak jste sám napsal), vůbec ničemu nevadí, když je tato informace součástí cesty. Tedy když přistoupím na váš pohled, že tečka na začátku znamená skrytý soubor. Mimochodem, Windows to mají už docela dlouho vyřešeno stejně. Skrytý je adresář Windows, adresář Program Files, soubor desktop.ini – podle cesty, ne podle nějakého atributu (u desktop.ini se atribut „skrytý soubor“ stále používá, ale to jen proto, že už v systému je, cesta by to vyřešila úplně stejně). Navíc i ve WIndows už se střel rozdíl mezi skrytý a systémový soubor – ty atributy se používají společně, a zobrazení se přepíná pro oba najednou. A přesně se tím označují soubory, které uživatel bezprostředně nepotřebuje ke své práci, a na jejichž cestách mu nezáleží. Takže Windows se v tomto odvracejí od svých DOSovských kořenů a dnes už používají prakticky stejný způsob, jako Linux. Akorát že ve světě Windows je to o něco zmatečnější, protože tam neexistuje jednoznačný způsob, jak něco označit za skryté/systémové, těch způsobů se tam používá víc paralelně.

Navíc vy na to jdete zcela opačně. Tvrdíte, že existuje nějaký atribut „skrytý soubor“, který se určuje tečkou na začátku názvu. Ono je to ale ve skutečnosti v Linuxu přesně naopak. Existují druhy souborů a adresářů, které uživatel bezprostředně nepotřebuje ke své každodenní práci. Ujal se dobrý zvyk tyhle soubory označovat tečkou na začátku, aby se řadily na jedno místo. Pak to někdo vylepšil, a přestal tyhle soubory zobrazovat úplně (pokud si je uživatel explicitně nevyžádá). Protože se ty soubory tedy ve většině programů běžně nezobrazují, říká se jim „skryté soubory“. Ve skutečnosti jsou to ale pouze soubory s tečkou na začátku, soubory s atributem „skrytý“ Linux nezná.

Otázka tedy zní: „existuje nějaký rozumný případ použití (případného nového) atributu skrytý soubor/adresář?“ Program, který vám nacpe adresář někam, kam ho nechcete, mezi rozumná použití nepočítám…

[Miloslav Ponkrác]

Já tedy debatu jen tak letmo přehlédl (takže toto je globálnější reakce nejenom na Vás), ale můj názor je, že tečková konvence skrytého souboru je jen z nouze ctnost.

Jinak nastavení skrytosti souboru se provádí poměrně často. A nejen před uživatelem - například já nastavuji, které soubory z projektu budou skryté pro CVS/SVN.

Nastavuji, které souboru kdo smí vidět na počítače - pokud máte děti, je to skvělá věc - a dá se to rozumně využít - jistě si dokážete představit fotky, které uživatel "tatinek" chce vidět, a uživatel "dcera" by vidět neměla. A jak to má chudák program vědět, které fotky jsou které?

Ale celá debata je ryze akademická - pokud žádné skrytí souboru nebude ve fs, pak se navirtualizuje nad ním.

Mě se osobně moc líbí přístup na Mac OS X. Každý soubor má řadu atributů, které se sdruží se souborem - třeba typ souboru, ale i aplikace, která ho vytvořila, a další - a moc moc se to pro praxi hodí a je to víc užitečné, než se zdá.

[Filip Jirsák]

Já tedy debatu jen tak letmo přehlédl (takže toto je globálnější reakce nejenom na Vás), ale můj názor je, že tečková konvence skrytého souboru je jen z nouze ctnost.

Pokud považujete tečku před názvem souboru za označení atributu „skrytý“. Což je podle mne pohled naruby, a ve skutečnosti většina programů soubory s tečkou defaultně nezobrazuje, proto vypadají jako skryté.

Jinak nastavení skrytosti souboru se provádí poměrně často. A nejen před uživatelem - například já nastavuji, které soubory z projektu budou skryté pro CVS/SVN.

Což nezařídí jeden univerzální atribut, ale je potřeba říci, která aplikace si nemá kterého souboru všímat. CVS to řeší pomocnými soubory, mohlo by to řešit přes rozšířené atributy.

Nastavuji, které souboru kdo smí vidět na počítače - pokud máte děti, je to skvělá věc - a dá se to rozumně využít - jistě si dokážete představit fotky, které uživatel "tatinek" chce vidět, a uživatel "dcera" by vidět neměla. A jak to má chudák program vědět, které fotky jsou které?

To už bylo dávno vynalezeno a říká se tomu uživatelská práva. Chudák program to pozná tak, že fotku s právy r-------- a vlastníkem tatínek mu jednoduše jádro nedovolí přečíst, pokud jeho EUID != EUID tatínek nebo 0.

Mě se osobně moc líbí přístup na Mac OS X. Každý soubor má řadu atributů, které se sdruží se souborem - třeba typ souboru, ale i aplikace, která ho vytvořila, a další - a moc moc se to pro praxi hodí a je to víc užitečné, než se zdá.

Na to už nástroj máme – rozšířené atributy. Teď už „zbývá“ jen zavést nějakou množinu standardních názvů atributů a naučit programy je používat. Typem souboru a kódováním u textového souboru by se mohlo začít.

[Luk]

To už bylo dávno vynalezeno a říká se tomu uživatelská práva. Chudák program to pozná tak, že fotku s právy r-------- a vlastníkem tatínek mu jednoduše jádro nedovolí přečíst, pokud jeho EUID != EUID tatínek nebo 0.

Ovšem adresářová položka se zobrazí. Takže pokud tam bude hromada fotek s názvy jako horny-lesbians-32.jpg a nejde to otevřít, začne dítko (většinou spíš syn než dcera) hloubat, jaké že skvělé fotky jsou před ním utajeny. Kdyby se nezobrazovalo nic, žádné takové choutky by to negenerovalo (ponechávám stranou fakt, že zrovna tenhle druh fotek dítěti neublíží)

Teď už „zbývá“ jen zavést nějakou množinu standardních názvů atributů a naučit programy je používat. Typem souboru a kódováním u textového souboru by se mohlo začít.

Už poněkolikáté tu opakuji, že to už do značné míry existuje. Jen to začít opravdu používat.

[Zdenek.Z]

Tak se na adresář nastaví chmod go-rwx a je to. Teď mám pocit, že nerozlišujete mezi skrytím souboru pro "kosmetické" účely a mezi zakázáni zobrazení souboru.

[Luk]

V uvedeném případě (stejně jako v jiných, o kterých tu je řeč), jde o kosmetické skrytí souboru. Kdo šťourá, ten vyšťourá. Mám pocit, že kdo trochu přemýšlí, hesla velké části uživatelů (zejména těch, které zná) trefí maximálně na několik pokusů

[Filip Jirsák]

Takže ty fotky „zabezpečíte“ před někým, kdo je schopen zjistit heslo ostatních uživatelů a přihlásit se pod nimi, ale nedokáže si zobrazit skryté soubory? A že si s trochou námahy může obsah těch souborů zobrazit kdokoli vám nevadí, ale že může vidět jejich názvy je problém? Tohle je opravdu zbytečné řešit na úrovni jádra, to ať si raději udělá nějaká distribuce, kde se všichni budou přihlašovat pod rootem a přístupová práva pak budou uložena v rozšířených atributech, a budou se jimi řídit (jen) všechny open i save dialogy Qt nebo GTK.

[Luk]

Znovu opakuji, já jsem s tím nezačal. Ale když už se to tu řeší, tak prostě odděluji dvě věci - kosmetické skrytí (nemusí být neprůstřelné, ale ať je důkladné - vůbec jsem nehovořil o řešení na úrovni jádra) a záležitosti bezpečnosti.

[xkucf03]

Vy ty vygenerované dokumenty PDF asi k něčemu chcete.

Já je nechci Do té složky se generuje každý takto vytisknutý dokument (asi jako záloha nebo temp), ale uživatel si v dialogu při každém tisku volí, kam to uložit. Takže tuto složku opravdu nepotřebuji (max. jednou za čas, když ji chci promazat nebo hledám něco starého). Proto je pro mě možnost skrytí souborů/složek užitečná.

[rADOn]

Tak a konecne je to venku. Zkratka mas problem s nejakou aplikaci a nejlepsi reseni je hacknout kernel. Skvelej napad, budeme kazdy lamicce upravovat kernel kvuli chybam v jeji oblibeny aplikaci a az bude mit kernel deset giga budeme se placat po ramenou jak je to uzivatelsky privetivy. Aspon lamicky svoje nabuseny stroje na neco vyuzijou.

Mam napad, neztracej cas s nama ubozakama ktery nerozumeji nepopiratelnym vyrokum a napis to. Zdrojak mas, kompiler mas, cas na blbosti evidentne taky... casem zjistis proc toho tvuj bajecny napad vic rozbije nez spravi.

[xkucf03]

Některé komentáře nestojí za odpověď.

[rADOn]

A ten muj to jak vidno stoji kdyz se aspon jedna odpoved nasla

Me nedela poteseni byt takhle neurvaly ale kdyz jsem popsal jen cast toho co to obnasi pod kapotou, dostalo se mi odpovedi

Používání tečky pro skrývání je chyba návrhu a její obhajování je pouze z nouze ctnost.

Opravdu nevim co na tak fundovany a technicky presny argument odpovedet. A nebyt sprosty. Jestli chces muzu ti sepsat hruby technicky nastin co by skryvani pres atribut obnaselo - ale mam pocit ze to stejne nechces slyset.

[Milan Jurik]

Defragmentace a shrink ZFS jsou dve pekna temata pro diplomku. Kdyby se treba nasel zajemce

[Franta]

Tou diplomkou myslis, aby to nekdo naprogramoval?

Protoze ani jedno z toho ZFS neumi.

P.S. sorry za chybejici hacky carky, mam tu "madarskou" klavesnici

[Milan Jurik]

Mno, hlavne rozmyslet pekne design, jak to vlozit dovnitr. Celkovy design ZFS tomu nebrani, jen proste nikdo zatim to nebere jako prioritu -> moznost pro studenty se na tom vyradit

[Robo]

No ja by som radsej bral viacero filesystemov specialne optimalizovanych pre urcite typy dat. Nie jeden super univerzalny, namakany. Jedine, ze by bol vo vsetkych parametroch najlepsi - ale taky tazko bude existovat ;)

[Filip Jirsák]

Daleko víc, než (podle mne zbytečný) atribut „skrytý“ bych ocenil standardní název pro rozšíření atribut určující mime typ dat souboru případně spolu s kódováním. Protože je ostuda, že typ dat a kódování umí přenést kdejaký síťový protokol, ale při uložení souboru na disk si musíte typ dat a kódování poznamenat jako součást dat, což je poněkud zacyklené.

[xkucf03]

MIME typ by byl fajn, pak bychom skoro nepotřebovali přípony (jen by to chtělo zajistit uchování typu v jiných FS, např. automatickým převodem na příponu). Luk už tady odkazoval Freedesktop, kde mime i kódování už mají. Nejlepší by bylo, kdyby se automaticky předpokládalo UTF-8 a jiné kódování by se použilo pouze tehdy, pokud by existoval atribut user.charset.

[Andrej]

V zásadě jde o moc hezký sen a nikdo by jistě nic nenamítal, kdyby se stal realitou.

S tou defragmentací je trochu problém. U poloprázdného disku není potřebná. U téměř zaplněného disku zase prozměnu není vůbec proveditelná. Defragmentace je tedy užitečná a zároveň možná pouze po uvolnění velké části dosud téměř zaplněného oddílu. To se ale nestává až tak často.

Pokud jde o různá metadata, v dnešní době je potřeba uvažovat také o přenositelnosti na jiné [souborové|operační] systémy. Zatímco ACL s trochou nastavování přenášet lze, existuje spousta příkladů nepřenositelných řešení. Například NTFS. Má spoustu nastavení, pokud jde o oprávnění. Je tam obdoba ACL s víc než deseti různými oprávněními, která lze u souboru nastavit pro každého uživatele a každou skupinu zvlášť. Při zkopírování těchto dat na UNIX (třeba i přes Sambu) však všechna metadata vezmou za své. Naopak UNIXové ACL se zase nijak nepromítnou do souborového systému NTFS.

Zmíněný problém mě nepálí, protože Windows nikde nemám. Chci tím jen ilustrovat fakt, že některé nápady by vyžadovaly buď modifikaci všech dosavadních souborových systémů, nebo přechod na jeden jediný. Bez podpory rozšířených atributů přinejmenším v NFS nemá smysl o nich vůbec uvažovat.

[xkucf03]

U poloprázdného disku není potřebná. U téměř zaplněného disku zase prozměnu není vůbec proveditelná.

Stačí defragmentovat průběžně, třeba každý večer a pak k frangmentai prakticky docházet nebude ani při větší zaplněnosti disku. Ale abych se přiznal, tak v dobách, kdy jsem měl Windows, jsem byl líný dělat defragmentaci často, takže se mi disk stejně fragmentoval

[Josef Kufner]

Tak si ten nástroj napiš

#!/bin/bash
# Cool Defragmentation Tool
mountpoint="/"
tmp="$(mktemp -d)"
 
find "$mountpoint" -mount -type f \
| while read f
  do
      cp -a "$f" "$tmp/cur" && mv -u "$tmp/cur" "$f"
  done

[Michal Vyskočil]

Nebo používej xfs.

[xkucf03]

Jako vtip dobré, pro praxi nepoužitelné.

Pokud bych to měl brát vážně, tak, co se stane, když budu přistupovat k právě "defragmentovanému" souboru? Myslím, že nám je to oběma jasné

[Filip Jirsák]

Nedefragmentuje se?

[Luk]

Pokud byl otevřen jen ke čtení, nestane se nic (kromě toho, že po určitou dobu budou existovat dva exempláře, starý a nový). Pokud bude ale otevřen k zápisu a nebude mandatorně zamčen, snadno se vyrobí soubor s nekonzistentními daty.

[Josef Kufner]

Všimni se soubor nejdříve kopíruji, takže se udělá vlastně snapshot defragmentovaného souboru. Poté upravím záznam v adresáři (přesun nekopíruje data, možná by se to dalo považovat i za atomickou operaci), ale jen pokud se předchozí parametr nezměnil (parametr -u), takže se nestane vůbec nic (ani defragmentace) a změny budou zachovány.

Je tam pár drobností, jako že onen dočasný soubor musí být na stejném disku jako je defragmentován a taky uklidit dočasný adresář, ale to jsou opravdu jen kosmetické detaily.

[xkucf03]

Tak hodně štěstí Já si raději podobné žonglování se soubory odpustím. V případě potřeby můžu udělat dump/restore. Ale pořád je to nouzovka oproti plnohodnotné defragmentaci implementované na úrovni FS, která umožní transparentní a nerušenou práci se soubory během defragmentace. Na jednom stroji mám XFS, tak si s tím tak trocu hraju...

[Luk]

Všimni se soubor nejdříve kopíruji, takže se udělá vlastně snapshot defragmentovaného souboru.

Jenže v situaci, kdy je původní soubor otevřený k zápisu, může dojít ke změně již během toho kopírování (není atomické!). Takže již snapshot může být nekonzistentní. Aby byla konzistence téměř zaručena, musel by se zaznamenat čas před začátkem kopírování a po něm, a tyto údaje porovnat (a v případě odlišných hodnot buď soubor vynechat nebo ho zkopírovat znovu). Ale ani toto nebude stoprocentní, protože soubor může být namapovaný do paměti a bez explicitní synchronizace se AFAIK neaktualizuje čas změny.

[Filip Jirsák]

Pokud ten soubor bude otevřen pro zápis, bude aplikace mít nějaký deskriptor souboru svázaný s číslem inode. Když se soubor okopíruje, vznikne druhé číslo inode, a když se přesune zpět, přesune se jen záznam v adresářové struktuře. Takže po provedení příkazu budou existovat dva soubory, na jeden bude mít odkaz program a nebude na něj žádný odkaz v adresářové struktuře, na druhý bude odkaz v adresářové struktuře. Nebo to bude jinak?

[Luk]

Jde o to kopírování. Během něho může vzniknout nekonzistence (nehovořím o tom, že pozdější změny v původním souboru budou ztraceny). Kromě toho si uvedený "defragmentor" správně neporadí s hardlinky, ale to už je detail.

[Filip Jirsák]

Máte pravdu, na změny během kopírování jsem nemyslel. Tedy ne že bych chtěl disk takhle defragmentovat, jenom je to hezká ukázka toho, že souborový systém linuxu je celkem robustní.

Nemělo by ale cp před začátkem kopírování získat zámek pro čtení na celý soubor, a uvolnit jej po zkopírování celého souboru? Pak by u aplikace správně používající zámky neměl nastat problém…

[Luk]

Nemělo by ale cp před začátkem kopírování získat zámek pro čtení na celý soubor, a uvolnit jej po zkopírování celého souboru? Pak by u aplikace správně používající zámky neměl nastat problém…

Jenže zámky na souborech používám jen poměrně málo aplikací. Prostě se počítá s tím, že tam nikdo jiný hrabat nebude. Dalo by se to ale řešit sledováním událostí pomocí inotify (IN_MODIFY - i když si teď nejsem úplně jistý, jestli se tato událost generuje i při změně přes mapování - obávám se, že ne). Pokud během kopírování přijde tato událost, buď se kopíruje znovu nebo se soubor ignoruje.

[Filip Jirsák]

Jenže zámky na souborech používám jen poměrně málo aplikací. Prostě se počítá s tím, že tam nikdo jiný hrabat nebude.

To ano, ale to už je pak chyba té aplikace. Když chce konzistentní soubor, má si ho zamknout

[Miloslav Ponkrác]

Aplikace, která požaduje konzistentní práci se souborem a nezamkne si ho, si nic jiného, než sletět na hubu nezaslouží a uživatel, který používá takovou aplikaci, nechť se nediví, přijde-li o data. A to jsem to chtěl napsat poněkud drsněji.

Pokud prostě programátor píše špatně, není to omluva pro to, proč nepoužívat správnou techniku - zámky v případě kdy je to potřeba.