[Linux/BSD] NTFS-alike filesystem

[Marten]

Ik ben op zoek naar een filesystem voor mijn aankomende Linux/BSD (keuze heb ik nog niet gemaakt) installatie. De bekende ext2/ext3/reiserfs/etc vind ik echter niet acceptabel. Naar mijn mening gaat het mis bij een aantal eisen die ik stel:

1. File Permissions
Deze moeten min of meer zoals onder NTFS geregeld zijn. Met andere woorden:
- nette overerving van toegepaste rechten op hogere niveau's (geen chmod -R praktijken dus)
- rechten toepassen op meerdere users/groepen tegelijk (geen beperking tot alleen specifieke user/specifieke group/everyone, maar een volledige lijst)

2. Hidden bit
Ik vind persoonlijk *nix style van verbergen van bestanden dmv een "." vooraan de filename erg lelijk, en wel omdat de hidden status een stuk metadata is, welke op die manier vervlochten wordt met een ander stuk metadata, nl. de filename. Dit is niet iets wat je normaal gesproken wilt.
Bovendien wil ik in mijn installatie een tweede, alternatieve folderstructuur gaan hanteren, en dan wil ik niet de standaard *nix folders zien, maar alleen mijn eigen mirror van de standaardstructuur. Daarvoor moet ik dus de *nix folders verbergen, maar dat kan niet wanneer ik er een "." voor moet zetten (toch? of kan ik bij een linux from scratch de hele structuur an sich anders doen, ipv een mirror maken?).

Daarnaast moet het natuurlijk overweg kunnen met 2+ Gb etc, maar dat lijkt me duidelijk. Het liefst zou ik ook nog iets moois zien mbt metadata in zn algemeen, maar dat is niet echt belangrijk.

Ik heb geprobeert iets te vinden via Google/GoT Search, maar niets gevonden. Ik weet ook niet echt waar op te zoeken. Weet iemand een filesystem die aan bovenstaande dingen (deels) voldoet?

[Tomaat]

Dit is nu precies wat ik ook graag zou zien.. De rechten structuur zoals deze met ext2 (Journaled ext3) word gehanteerd is toch niet meer "van deze tijd!".
Zelfs met NTFS4 (WinNT4 dus) kun je nog betere structuren maken.

Nu heb ik ooit iets gelezen over ACl's..hiermee zou je wel ala NTFS rechten kunnen toewijzen. Maar dit schijnt een echte nachtmerrie te zijn aangaande de configuratie van het geheel.

[ Voor 3% gewijzigd door Tomaat op 10-06-2004 19:22 ]

[Verwijderd]

De nieuwe Reiserfs4 komt wel uit...weet niet of die alles wat hierboven genoemd wordt kan, maar hij schijnt super degelijk en super snel te zijn. Iets wat NTFS nogal mist naar mijn mening...NTFS is namelijk in vergelijking met andere filesystems enorm traag.

[ Voor 29% gewijzigd door Verwijderd op 10-06-2004 19:27 ]

[Bananenplant]

hmm, je zou eens kunnen kijken naar XFS, die heeft POSIX-nogwat-extenties, volgens mij is dat iig qua permissies hetgene wat je wilt. maar pin me er niet op vast, ik heb het nog niet echt gebruikt ofzo

(ik zag het staan (en heb het aangezet) bij het bakken van m'n kernel)

[ Voor 16% gewijzigd door Bananenplant op 10-06-2004 20:36 ]

[Jrz]

Je zou eens moeten kijken naar ACL's onder FreeBSD 5.x.
3 links die ik even snel kon vinden:


http://www.freebsd.org/do...ooks/handbook/fs-acl.html

http://ezine.daemonnews.org/200310/acl.html

http://www.onlamp.com/pub/a/bsd/2003/08/14/freebsd_acls.html

[_JGC_]

Mja, alle filesystems hebben tegenwoordig in linux support voor ACLs, sinds 2.6.6 heeft ook Reiserfs dit. Het wordt ook wel Extended Attributes genoemd voor deze filesystems.

Als je gewoon POSIX ACL support in je kernel hebt zitten, en je filesystem is gemount met deze opties (vraag me af of dat nodig is, maar whatever), dan kan je gewoon vanuit windows met samba NTFS style permissions toewijzen. Heb het een halfjaar geleden ooit eens met FreeBSD 5.x geprobeerd, dit ging vlekkeloos. Linux moet dat ook gewoon kunnen.

Wat betreft hidden files: ben ik met je eens, hoe vaak zie ik wel niet desktop.ini in mn roaming profile opduiken in allerlei folders

[Marten]

Ik heb eens naar ALCs gekeken, en ACLs zijn inderdaad een stuk beter dan de standaard manier. Alleen jammer dat het geen echte (dynamische) inheritance heeft:

Windows ACLs have had an inheritance model that was similar to the POSIX ACL model. Since Windows 2000, Microsoft uses a dynamic inheritance model that allows permissions to propagate down the directory hierarchy when permissions of parent directories are modified. POSIX ACLs are inherited at file create time only.

Reiser4 ziet er ook veelbelovend uit. Met name de afhandeling van het opslaan van metadata in via een "bestand-dat-ook-een-soort-directory" methode vind ik erg netjes. Bovendien bied zoiets perspectieven: de file is executable en de data die de executable nodig heeft kan staat in de subdirectories die in die file-als-directory staan (MacOSX Application.app anyone?)

[Bananenplant]

mag ik heel stom vragen hoe je die dingen dan toepast? met chmod

[Marten]

ucchan schreef op 10 juni 2004 @ 22:17:
mag ik heel stom vragen hoe je die dingen dan toepast? met chmod

Ja hoor, wat ik heb gelezen in die pagina's doe je dat met setfacl, en getfacl voor het opvragen. Voor voorbeelden zie deze link die Jrz gaf.

[mkools24]

Tomaat schreef op 10 juni 2004 @ 19:22:
Dit is nu precies wat ik ook graag zou zien.. De rechten structuur zoals deze met ext2 (Journaled ext3) word gehanteerd is toch niet meer "van deze tijd!".
Zelfs met NTFS4 (WinNT4 dus) kun je nog betere structuren maken.

LOL! Als je NTFS4 goed vindt dan kun je beter Windows gaan gebruiken
Als er iets kut en traag is dan is het NTFS4.
Ik vind EXT3 prima genoeg hoor

[Wilke]

mkools24 schreef op 11 juni 2004 @ 00:49:
LOL! Als je NTFS4 goed vindt dan kun je beter Windows gaan gebruiken
Als er iets kut en traag is dan is het NTFS4.
Ik vind EXT3 prima genoeg hoor

Dit soort trolls die niks toevoegen aan een topic mag je volgende keer dus gewoon voor je houden. Wat jouw mening is over NTFS en dat je ext3 wel prima genoeg vindt boeit namelijk niemand, tenzij je onderbouwt waarom.

[mkools24]

Wilke schreef op 11 juni 2004 @ 00:54:
[...]


Dit soort trolls die niks toevoegen aan een topic mag je volgende keer dus gewoon voor je houden. Wat jouw mening is over NTFS en dat je ext3 wel prima genoeg vindt boeit namelijk niemand, tenzij je onderbouwt waarom.

Het was niet als trollopmerking bedoelt, weet niet waar je dat vandaan haalt

NTFS is crap vergeleken linux ext3, het is traag en het is een kriem om een beetje
rechtenstructuur in te stellen, vooral in grote omgevingen.
Zeker NTFS4 gaat helemaal nergens over!
Als je kijkt hoe ze dat bij Novell en Unix doen dat is dat gewoon vele malen
beter.
Ik snap gewoon niet dat je zoiets uberhaupt onder linux zou willen hebben.

Zo beter?

[Bananenplant]

illuware schreef op 10 juni 2004 @ 21:26:
Ik heb eens naar ALCs gekeken, en ACLs zijn inderdaad een stuk beter dan de standaard manier. Alleen jammer dat het geen echte (dynamische) inheritance heeft:

Misschien ben ik nu een stomme , hoor... maar bedoel je niet gewoon iets als chmod -R ? Als je, zoals ik meen te lezen, attributen van de 'ouders' gaat erven, wat is de winst dan? Het lijkt me alleen maar nodeloos complex... maar goed, leg me vooral uit wat je ermee wint, ik vind dit wel interessant spul .

Reiser4 ziet er ook veelbelovend uit. Met name de afhandeling van het opslaan van metadata in via een "bestand-dat-ook-een-soort-directory" methode vind ik erg netjes. Bovendien bied zoiets perspectieven: de file is executable en de data die de executable nodig heeft kan staat in de subdirectories die in die file-als-directory staan (MacOSX Application.app anyone?)

Eventjes goed lezen... in oo-taal zou je dus een object hebben met als properties een executable en de data die erbij hoort... het klinkt inderdaad handig. Maar dan moet je wel zeker weten dat je geen shared libraries nodig hebt en het is zoals ik het interpreteer ook wat strijdig met de directory-opzet van het gemiddelde unix-systeem.

Wat me trouwens er ook op brengt... die 4 bytes die je aan permissies (als je erover nadenkt heel erg "joepie, we kunnen het zo mooi in slechts 4 bytes proppen :+" overkomt, ouderwetsche zuinigheid ofzo ) in kan stellen zijn nogal ingeburgerd in velerlei unices, dus in zekere zin heb je als je een fs gaat ontwikkelen daarvoor een interface van operaties die je ermee moet kunnen uitvoeren zodat het bruikbaar is voor een unix-systeem. Ik denk dat als je uitbreidingen gaat maken van iets dat al sinds zo 1970 (!) bestaat (aanname, ik weet zo 123 niet zeker of unix begonnen is met dergelijke fs-es) het wel zaak is dat je een standaard aanhoudt, aangezien het wel handig is als je een universele interface hebt van attributen die je kunt instellen, vooral als het OS zelf daadwerkelijk iets met die attributen gaat doen. Het lijkt me vrij vervelend als bijvoorbeeld linux ext3 en opvolgers als standaard adopteert met bijbedachte features die ontbreken in xfs, reiser, etc, waardoor je je keuzevrijheid van fs kwijt bent.

Verder (dit is misschien offtopic, maar ik vind het gewoon interessant spul) vraag ik me naar aanleiding van die troll wel af of er ook degelijke uitgebreide vergelijkingspagina's op het net staan (ik ga morgen wel googlen, het is nu laat ). Bij open source-projecten kun je in theorie de devvers vragen hoe de algoritmen werken en met een complexiteitsanalyse een theoretische performancevergelijking opstellen .

[igmar]

[quote]illuware schreef op 10 juni 2004 @ 19:14:
1. File Permissions
Deze moeten min of meer zoals onder NTFS geregeld zijn. Met andere woorden:

- nette overerving van toegepaste rechten op hogere niveau's (geen chmod -R praktijken dus)

POSIX ACL's doen dat. NT / 2k doet dit net zo min : Je moet als je de zaken wijzigt nog steeds bij 'extended' een vinkje aanklikken, en dan worden de rechten recursief geregeld.

- rechten toepassen op meerdere users/groepen tegelijk (geen beperking tot alleen specifieke user/specifieke group/everyone, maar een volledige lijst)

Dat kunnen de POSIX ACL's ook. Standaard in 2.6, een patch nodig met 2.4.

2. Hidden bit

Ik vind persoonlijk *nix style van verbergen van bestanden dmv een "." vooraan de filename erg lelijk, en wel omdat de hidden status een stuk metadata is, welke op die manier vervlochten wordt met een ander stuk metadata, nl. de filename. Dit is niet iets wat je normaal gesproken wilt.

Hidden bestanden bestaan niet in *NIX, en dat willen velen (waaronder ik) ook graag zo houden. Wat rest is de chaos die MS d'r van gemaakt heeft : hidden, system, readonly attributen, en dat soort dingen horen d'r niet eens te zijn. Een vieze hack is de juiste term.

Bovendien wil ik in mijn installatie een tweede, alternatieve folderstructuur gaan hanteren, en dan wil ik niet de standaard *nix folders zien, maar alleen mijn eigen mirror van de standaardstructuur. Daarvoor moet ik dus de *nix folders verbergen, maar dat kan niet wanneer ik er een "." voor moet zetten (toch? of kan ik bij een linux from scratch de hele structuur an sich anders doen, ipv een mirror maken?).

Leg uit ? Hier kan ik niks van maken eerlijk gezegd.

[Verwijderd]

Mja, over de permissies is al lang en breed gesproken. Zie ACL's daarmee kun je wat je wilt (en als je je permissies wilt overerven at modification time, wie let je om hier een patch of een aangepaste setfacl util voor te schrijven?)

Over je alternatieve filesystem structuur. Ja dat kan, maar ga er alvast vanuit dat dat flink wat werk kan gaan worden afhankelijk van de methode die je gebruikt. Als je echt een compleet alternatief filesystem wilt inrichten, is linux from scratch mischien wel wat voor je. Dat is mischien nog wel de enige distro waar je makkelijk een compleet alternatieve filesystem layout voor kunt maken. Ander alternatief is werken met symlinks (of mounten met de --bind optie), maar dat vind ik persoonlijk een ranzige optie.

[ Voor 3% gewijzigd door Verwijderd op 11-06-2004 09:17 ]

[Freak_NL]

Een "alternatief" filesystem is er al voor de normale desktop gebruiker. Vanaf Gnome 2.6 heb je de "computer://" locatie met daarin je voor de gebruiker toegankelijke partities (muziek, films, data?), de CD/DVD drives en de home folder. In de filebrowser of de filedialogen zie je de met een . beginnende mappen ook niet standaard.

KDE zal het op een soortgelijke manier aanpakken lijkt me. (ik gebruik KDE zelden, dus daar mag iemand anders me op aanvullen)

Als systeembeheerder (root) wil je wel graag de traditionele *nix mappen zien lijkt me. Als je dat nog steeds onprettig vindt, kijk dan eens naar GoboLinux.

[rollebol]

igmar schreef op 11 juni 2004 @ 09:02:
Hidden bestanden bestaan niet in *NIX, en dat willen velen (waaronder ik) ook graag zo houden. Wat rest is de chaos die MS d'r van gemaakt heeft : hidden, system, readonly attributen, en dat soort dingen horen d'r niet eens te zijn. Een vieze hack is de juiste term.

Dat ben ik niet helemaal met je eens. Hidden files bestaan wel degelijk in UNIX. Dat zijn namelijk (zoals je natuurlijk wel weet) bestanden met een punt ervoor, en het is de afspraak dat die in de user interface niet pontificaal voor de neus van de gebruiker worden gezet als die een file listing aanvraagt, maar zonder veel moeite toch zijn te tonen. Ik zie niet hoe dit anders is dan in (bijvoorbeeld) Windows, en waarom het beter is. Sterker nog, mij lijkt een vieze hack de juiste term.

Ik zal maar niet beginnen over read-only attributen en of die er wel of niet horen te zijn.

Overigens zijn ACLs één van de dingen die door 'het bedrijfsleven' (om maar even te generaliseren, ik hoef geen individuele tegenvoorbeelden te horen) als wenselijke uitbreiding van Linux werd geacht. Omgevingen als HP/UX bevatten al vele, vele jaren access control lists, net als Windows toen het volwassen werd.

[balk]

Je zou eens kunnen kijken naar de patches die gebruikt worden bij GoboLinux
Deze distro hanteert een alternatieve directory structuur en verbergt sommige dirs voor users.
uit een artikel

The GoboLinux directory structure brings a fresh, clean look the Linux system, but the presence of the legacy tree, while necessary, takes some of this beauty away. Mac OS X uses a "dirty trick" to cover up its Unix nature: the Finder won't show the Unix directories, but you can see them from the command line. In Linux we have many different ways for looking at the filesystem (shells, file managers, browsers...), so we had to go deeper to have a clean-looking system. GoboHide is a (obviously optional) kernel patch plus userland application written by Lucas Correia Villa Real and Felipe Damásio that effectively implements "hidden files" on Linux (way beyond dot-files, which are implemented on UI-level just like Finder does).

bron

[ Voor 65% gewijzigd door balk op 11-06-2004 14:00 . Reden: kwootje erbij ]

[Bananenplant]

hmm, waarom zou je dat willen? is toch niet echt noodzakelijk lijkt me

[balk]

ucchan schreef op 11 juni 2004 @ 14:09:
hmm, waarom zou je dat willen? is toch niet echt noodzakelijk lijkt me

dat is toch wat TS wil?

[Bananenplant]

mwa, ik bedoel meer dat hele idee van die distro

maar goed, misschien maak ik teveel discussie van een concrete vraag

[Verwijderd]

Hidden files kunnen idd voordelen hebben op dotfiles. Bij Gnome is dit goed merkbaar.

Mail settings etc. staan in ~/evolution/ Dat mapje is dus zichtbaar voor de gebruiker. renamen is veel werk. En ik heb al een jaar of 6 een mapje wat ~/doc heet. maar volgens Gnome moet dat ~/Documents heten. dus ik ln -s dat aan elkaar, maar dan hoef ik ~/doc niet meer te zien, maar hij moet wegens compatibility blijven bestaan.

Andersom kan het ook ~/.giFT/completed/ wil ik graag wel zichtbaar hebben. Daarom het ik dat gelinkt aan ~/giFTcompleted.

[Freak_NL]

Hidden files kunnen idd voordelen hebben op dotfiles. Bij Gnome is dit goed merkbaar.

Mail settings etc. staan in ~/evolution/ Dat mapje is dus zichtbaar voor de gebruiker. renamen is veel werk. En ik heb al een jaar of 6 een mapje wat ~/doc heet. maar volgens Gnome moet dat ~/Documents heten. dus ik ln -s dat aan elkaar, maar dan hoef ik ~/doc niet meer te zien, maar hij moet wegens compatibility blijven bestaan.

Andersom kan het ook ~/.giFT/completed/ wil ik graag wel zichtbaar hebben. Daarom het ik dat gelinkt aan ~/giFTcompleted.

Gnome gebruiker?

code:

echo "evolution" >> ~/.hidden
echo "doc" >> ~/.hidden

Nu is map evolution verborgen in Nautilus.

giFT is volgens mij heel goed instelbaar, anders ligt de fout gewoon bij de ontwikkelaars van giFT.

Een map "Documents" verplicht? Welke applicatie dwingt dat af? Gnome applicaties niet bij mij. OpenOffice.org ook niet. Lijkt me weer een "bug" van een specifieke applicatie.

hmm, waarom zou je dat willen? is toch niet echt noodzakelijk lijkt me

In plaats van het bijhouden van meta-informatie over welke bestanden bij welk pakket horen (zoals o.a. Gentoo dat bijvoorbeeld doet) zodat je een pakket bijvoorbeeld later weer kan verwijderen, gebruikt GoboLinux het filesystem voor deze informatie. Of dit voordeliger is t.o.v. de tradiotionele manier is betwistbaar, maar de GoboLinux aanpak is zeker een interessante "proof of concept".

[Verwijderd]

Freak_NL schreef op 12 juni 2004 @ 15:17:
[...]

Gnome gebruiker?

code:

echo "evolution" >> ~/.hidden
echo "doc" >> ~/.hidden

Nu is map evolution verborgen in Nautilus.

Das leuk, maar ls geeft ook in gnome-terminal de mappen gewoon weer. Ik kan natuurlijk ls wel gaan hacken, maar een algemene oplossing is netter.

giFT is volgens mij heel goed instelbaar, anders ligt de fout gewoon bij de ontwikkelaars van giFT.

Wat ik daarmee bedoelde te zeggen: Waarom is niet alles gewoon hidden en dat je dan een link maakt als je iets wel wilt zien...dan hoef je dus niet met mv te werken.

Een map "Documents" verplicht? Welke applicatie dwingt dat af? Gnome applicaties niet bij mij. OpenOffice.org ook niet. Lijkt me weer een "bug" van een specifieke applicatie.

Probeer Gnome 2.6 is...
Dit staat volgensmij ook in een of andere freedesktop.org standaard.

[Freak_NL]

Probeer Gnome 2.6 iseens...
Dit staat volgensmij ook in een of andere freedesktop.org standaard.

Ik draai Gnome 2.6.

Ik kan in de fd.o specs geen verwijzing vinden, weet je zo welke specificatie dit is? De "XDG Base Directory Specification" lijkt erop, maar daar is alles instelbaar door de gebruiker, geen verplichte mappen.