|
Diese Diskussion wurde archiviert.
Es können keine neuen Kommentare abgegeben werden.
|
|
|
|
 |
|
|
|
|
|
|
|
Jep, die haben das auch recht gwand geloest - trotz sehr weitgehender Unixaehnlichkeit. Der OS/2 Weg war ja fast sowas wie die Header einer MIME Mail (oder einer HTTP Uebertragung), also (fast) beliebieg viele Kennzeichner/Wert Paare.
Alles moegliche wird als Filesysteme gebastelt (fuer Linux), aber richtige Fortschritte seh ich nicht - dabei waere gerade mit MIME das Metadatenthema als echter anerkannter Standard schon da.
Gruss
H.
|
|
|
|
|
|
|
|
|
|
|
|
|
Da hab' ich doch eine Idee: Warum nicht "einfach" 'n weiteres Linux-Filesystem hacken, welches sich schlicht über beliebige andere Filesysteme legt, aber Metadaten in den Filestream einbaut? Soweit ich es überblicke ist der Kernel sogar so flexibel aufgebaut, daß dieses virtuelle FS auf das physische zugreifen könnte, ohne das physische in den Userspace einzublenden (mounten).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Hmm - also das mit dem reueberlegen ist nicht so das wahre - es erlaubt naemlich immer noch mit tools die auf das darunterliegende System zugreifen Inkonsistenzen zu erzeugen.
(Wobei man in dem fall gleich das nachmachen koennte was OS/2 auf FAT laufwerken macht - zwei Dateien \ea data. sf und \wp root. sf die die Metainformation vorhaelt)
Es sollte also schon ein System sein das in sich geschlossen ist, und direkt im System gemounted wird. Ein Ausgehen von einem anderen unterliegenden System waer schon nicht schlecht - im Prinzip braucht man nur einen Mechanismus um zu einem Dateieintrag noch weitere 'Dateien' zu hinterlegen. Im Minimalfall reicht eine weitere Kette (iNode), in der dann die Metadaten abgelegt werden. D.h. man kann da dann alle Metainformationen da reinpacken. Mehrere haetten den vorteil das man tatsaechlich verschiedene 'Zweige' haben kann - so wie der Mac mit seiner unterscheidung in resource fork(s) und data fork.
Im Ext2fs liesse sich das ganze schoen im erweiterten Dateieintrag unterbringen. Nur ein paar systemtools muessten natuerlich angepasst werden um nicht mengenweise unverlinkte iNodes anzuzeigen (und zu reparieren versuchen)
Genaugenommen, wenn wir nur den Mimetyp hinterlegen wollen - also nicht gleich die Superloesung, dann passt das auch gut direkt in den Dateieintrag von Ext2fs. Das ganze hat auch den Vorteil das es extrem schnell ist.
Ein anderer Weg fuer beliebige Dateisysteme waere das darueberstuelpen indem man fuer jede Datei ein Dir anlegt (das sich nur nicht als solches zeigt), welches dann als 'echte' dateien einmal die Datendatei, und zum anderen beliebige Metadateien enthaelt. Das liesse sich ueber jedes Dateisystem stuelpen, ist halt nur wie oben schon erwaehnt fehleranfaellig.
Gruss
H.
|
|
|
|
|
|
|
|
|
|
|
|
|
Hey, die Directory-Idee ist absolut sexy:
- Falls jemand auf die ungefilterte Partition zugreift ist bleibt sie lesbar.
- Legacy-Tools könnte man über einen weiteren
Mount-Point Zugriff auf die Metadaten geben. (Verweiste Metadaten können nicht entstehen, da wenn das Meta-Directory gelöscht wird. Aber ist es sindvoll, daß Meta-Dateien einfach im Filesystem verstreut werden dürfen: "cp cool-file/mime-type somewhere-else"...))
- Das Nachträgliche Überstülpen des MetaFS wird einfach: Ist beim ersten Zugriff die Datei wirklich 'ne Datei, wird das Meta-Directory angelegt, die Datei reingeschoben. Problem: Echte Verzeichnisse müßten gesondert markiert werden.
- Was ich nicht sehe ist die Fehleranfälligkeit: Das echte Filesystem läßt sich problemlos verstecken...
Direkt an den Inodes rumbasteln ist recht haarig: Wie Du selbst erkannt hast: Was passiert, wenn irgend 'n Tool das fs für'n reines ext2fs hält und anfängt rumzudoktorn? Außerdem wäre man auf ext2 festgelgt und hätte Probleme andere Filesystems, wie nfs, smbfs, reiserfs, ... drunterzulegen...
|
|
|
|
|
|
|
|
|
|
|
|
|
Weiss nicht, die suesse muesste sich schon ganz schoen auftakeln das ich sie Sexy finden koennte (und ich entsprechend Druck haben :)
Ich mach mal ein Beispiel, damit leichter wird:
Die Datei SexyPic welche ein GIF (image/gif) enthaelt soll im Verzeichnis /home/raffi/MeineBilder abgelegt werden.
Im Rahnmen des MetaFS schaut der Pfad fuer den Anwender dann so aus:
/home/raffi/MeineBilder/SexyPic
Der daraus resultirende Baum im darunterliegenden Verzeichnis schaut dann z.B. so aus:
a) Ein Metafile
/home/raffi/MeineBilder/SexyPic/
/home/raffi/MeineBilder/SexyPic/Data
/home/raffi/MeineBilder/SexyPic/Meta
Wobei Data die eigentliche Datei ist, und Meta Beschreibungen wie bei Mail/HTTP headern enthalt, also z.B.:
Content-Type: image/gif
X-Creator: MS-Paint
Oder aber
b) getrennte Dateien fuer jedes Metadatum:
/home/raffi/MeineBilder/SexyPic/
/home/raffi/MeineBilder/SexyPic/Data
/home/raffi/MeineBilder/SexyPic/Content-Type
/home/raffi/MeineBilder/SexyPic/X-Creator
Hier kann man sich vorstellen als wenn jede Datei in dem Verzeichnis ein Tag mit einem Inhalt ist - Das Data-Tag enthaelt halt zufaellig die Daten selbst.
(Im Rahmen von ext2/3fs koennte man die Headerwerte auch selbst in die Verzeichniseintraege der Tags packen)
Nun zu deinen Anmerkungen:
- Die Lesbarkeit ist nur im Sinne des darunterliegenden Systems gegeben. Schon beim Dateinamen scheiterts, da der der Applikation bekannte im darunterliegenden Filesystem unvollstaendig ist und auf ein Dir zeigt.
- Verwaiste Metadaten koennen durchaus entstehen, wenn ueber das darunterliegende FS zugegriffen wird, und z.B. nur der Data Zweig geloescht wird.
- Darueberstuelpen waere schon eine sache - ich dachte da aber eher an eine Emulationsschicht.
- Die Fehleranfaelligkeit ergibt sich zum einen dadurch das man mit 'alten' tools direkt auf das darunterliegende System zugreifen kann - und damit z.B. ein Textfile in die Datei speichern, obwohl der Typ image/gif sagt, oder anderes. Zum anderen dadurch das dier eine groessere Nummer von Operationen noetig sind, und entsprechend die Fehleranfaelligkeit steigt.
Und das fuehrt auch gleich zum naechsten Problem, naemlich der Performance - um jetzt zum beispiel an die Daten zu kommen sind mindestens 3 Zugriffe noetig, anstelle von 2en - Erst den Direintrag im 'originalverzeichniss lesen, dann den Verzeichnisblock mit den Metadatendateien lesen, und dann erst auf den ersten Datenblock der Datei zugreifen. im prinzip ist das wie als wuerde man alle dateien nurnoch ueber Links ansprechen ... ist zwar ganz nett, aber langsamm.
Ext2/3fs waere fuer mich der natuerlichste Kandidat um ein direkt im FS implementiertes metadatensystem zu machen. Das ext steht naemlich wirklich fuer Erweiterbar - die Direintraege sind (in Grenzen) gereits darauf vorbeteitet zusaetzliche Informationen zu tragen. Ausserdem laeuft erstmal alles was man so an tools hat weiter.
Die beschraenkung auf's ext2/3fs ist natuerlich ein Nachteil wenn man ein anderes verwendet - nur ist man solche ja bereits gewohnt. Dazu kommt das man die Emulationsschicht die ich mir fuer die 'alten' daten vorstelle hier auch verwenden kann. Dann ist es zumindest nicht schlechter als jetzt.
Meinung ?
Gruss
H.
|
|
|
|
|
|
|
|
|
|
|
|
|
Lesbarkeit: Wer sagt, daß das sexy picture "SexyPic" (und nicht
"SexyPic.jpg") heißen muß, wenn Du Legacy-Apps benutzen willst?
"rm SexyPic/Content" - Gosh! Brauchen wir also doch was anderes.
Wobei. Zumindest leicht zu entdecken ist so'ne Inkonsistenz. Hmm...
Hab gerade das gute alte ioctl in meiner System-Call-Suppe gefunden.
Wie wäre's mit
int fd = open("SexyPix", O_READ);
ioctl(fd, METAFS_SELECT_STREAM, "Content-Type");
Um Legacy-Apps zum Zuge kommen zu lassen, könnte man ja
zusätzlich über 'nen anderen Mountpoint die Filestreams in ein
Verzeichnis abbilden:
$ ls -l /home/raffi/Bilder/SexyPic
-rw-r--r-- 1 raffi users 1309015 Dez 07 22:55 SexyPic
$ ls -ld /legacy/home/raffi/Bilder/SexyPic
drwxr-xr-x 3 raffi users 1309015 Dez 07 22:55 SexyPic
$ ls /legacy/home/raffi/Bilder/SexyPic
Content
Content-Type
Context-Menu
Description
Notes
Wie, "Emulationsschicht"? Meinst kein File-System sondern 'n paar
Hacks im VFS?
Davor, daß image/sexy drauf steht, aber text/plain drin ist,
wird wohl auch das ausgefeilteste Filesystem nicht schützen können.
Wegen der Performance: Bei der Verzeichnis-Variante und bei der
Metablöcke-vor-den-Nutzdaten-Variante (die genau betrachtet ja auch die
Verzeichnis-Variante ist) kommt man wohl kaum um den Extra-Lesezugriff herum.
Also doch 'n Journal a'la OS/2?
Metadatenmanagement direkt in ein bestehendes Filesystem zu hacken macht
meiner Meinung nach wenig Sinn: Was machen die Leute, die nfs, smbfs, reiserfs,
... nutzen wollen/müssen, wenn sich das Metadatensystem etablieren sollte?
Ich bleib' dabei, das Metadaten-Management über den physischen Filesystems
angeordnet werden muss. Im Userspace, wie's momentan passiert ist es aus
bekannten Gründen auch fehl am Platz. Bleiben also die Varianten Hack im
VFS (Linux's filesystem abstraction layer) oder neues Filesystemmodul, das
Partitionen mit bestehenden Filesystem-Treibern lädt aber die zum Nutzer
durchgereichte Representation der Files manipuliert...
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Jeder Hack der zusätzliche Dateien direkt ins bestehende Filesystem einfügt ist nicht geeignet. Viel zu fehleranfällig.
Einzige Möglichkeit ist ein System wie es schon jetzt bei den RAID-Implementationen gemacht wird:
Ein neues Device wird erstellt, welches als Layer zwischen Anwender und darunterliegendem Filesystem liegt. Also z.B. /dev/metadata1. Jeder Zugriff darauf wird vom entsprechenden Code im Kernel gehandhabt. Nun ist es ein einfaches, bei jedem Zugriff je nach Bedarf (falls Metainformationen gefordert/geschrieben werden) die Metainfo von irgendwo (spezielle Partition, oder Datei) zu holen/schreiben, und sonst den Request einfach an das reale Device auf /dev/hda1 weiterleiten.
Einzige Fehlermöglichkeit ist dann, wenn jemand /dev/hda1 und /dev/metadata1 gleichzeitig mountet. Dann kann es zu Inkonsistenzen kommen. Man kann sich vorstellen, dass der Metadata-Code beim Mounten jeweils prüft, ob die Metadaten und die Dateien auf /dev/hda1 noch so sind wie beim letzten Schreibvorgang, und sonst die Metadaten an die Realität anpasst (dies falls jemand direkt auf /dev/hda1 geschrieben hat, ohne dass das Metadaten-Device gemountet war).
Viel besser wäre es sowieso, wenn sich der ganze Metadaten-Code in eines der bestehenden Journaling Filesysteme einbauen liesse, da diese sowieso schon ein Journal führen. Das Journal liesse sich noch um die Metadaten ergänzen.
--
paranoid? das sind andere
|
|
|
|
|
|
|
|
|
|
|
|
|
> [Metadaten ins Journal]
Da gehoeren sie vieleicht hin um die Wiederherstellung zu betreiben, aber fuer den normalbetrieb gehoert sie in den Katalogeintrag (Ich benutz jetzt mal absichtlich den alten Mainframebegriff :) - der ist ja schliesslich fuer Metadaten vorgesehen (Datum, Besitzer, Rechte, und in gewissen grenzen sogar Laenge sind bereits metadaten, welche nicht zum betrieb des FS noetig sind).
Gruss
H.
|
|
|
|
|
|
|
|
|
|
|
|
|
> [Dateiname]
Wer das sagt ? Der Anwender ! - Der Dateiname ist das was ein Anwender meint wie er seine Daten benennen will.
> [ioctrl]
Waere auf jeden fall ein Weg um die Aufrufe schonend durch den Kernal zu bringen - auch wenn es mir sympatischer waere neue Aufrufe zu definieren.
> [Emulationschicht]
Die war weniger gedacht um 'alten Anwendungen' die Daten zu liefern, als eher um zu 'alten Daten' entsprechende Metadaten zu liefern.
Also mal angenommen es gibt einen Aufruf
int fmetaget(FILE *fd, char *buf, int buflen, char *metatag)
fd ist eine geoeffnete Datei
buf,buflen der Buffer fuer den gefundenen Wert
metatag ein String mit dem namen der gesuchten Metainformation
Rueckgabewert waere die Laenge der gefundenen Information, oder negativ wenn Fehler
Also z.B. liefert
FILE fd = fopen("SexyPic", O_READ);
rc = (fd, buf, 200, "Content-Type");
rc=9 (ohne abschliessendes \0)
buf="image/gif"
Ist nun die Datei eine die auf einem Filesystem ohne Metadaten liegt, dann greift die Emulationsschicht, und versucht nach wie auch immer gearteten Reglen rauszufinden was es sein koennte - also z.B. koennte sie "image/gif" zurueckliefern wenn die Datei SexyPic.gif heisst. damit waere es zwar das gleiche Rumraten wie bisher, aber mit dem vorteil das es fuer das jeweilige Programm versteckt ablaeuft, spricht dort nicht programmeirt wird. Im Prinziep sind das ja, was etwa den content-type anbelangt, Dinge die Gnome oder KDE jetzt bereits machen ... jeder fuer sich und gleich schlecht (Mal nicht zu vergessen sowas dummes wie Webserver ... im Apache steckt jede menge rumgefummel um Content-Types zu erraten).
> [Metadatenmanagement in bestenedes System]
Wenn ein Filesystem das Ganze erlaubt, wie z.B. ext2/3fs ist es doof es obenauf zu setzen. Fuer andere Systeme muss natuerlich zumindest ein 'aufsatzmechanismus' her der die daten ablegt ... ich wuerde es da genau wie OS/2 machen - die hatten auf FAT Partitionen die Metadaten (hier Extended Atributes genannt) in einer Datei namens EA_DATA. SF gespeichert, bzw. von da wieder geholt.
> [Metadaten im / ueber dem 'physischen' Sytem]
Na ja, ist nur so das zum einen Metadaten bereits dort abgelegt werden, und zum anderen Filesysteme auch die zusaetzliche Ablage erlauben (zumindest einige).
Im VFS wuerd ich'S eher ungern sehen ... wobei das natuerlich der Richtige ort waere um die Abstraktion zu machen (also die Daten zusammenzupacken, egal ob sie als Subdirs, EA_DATA. SF oder im Verzeichniseintrag stehen).
Ach ja, nur am Rande, die Diskusion ist nicht neu, nur haben die bisherigen Projekte immer zurueckgeschreckt die sache im Kernel zu verankern, bzw. zu standardisieren.
Gruss
H.
|
|
|
|
|
|
|
|
|
|
|
|
|
#!/usr/local/bin/eigenesprogramm
#$
hmmm warum verpasst man nicht jeder Datei einen Header für Metadaten wie er bereits für scripte genutzt wird?
Es müsste lediglich die eigentliche Datei von den
Metadaten trennen um sie zu benutzen das liese sich auf jedem FS einsetzen und evtl als Kerneltreiber
implementieren.
|
|
|
|
|
|
|
|
|
|
|
|
|
Kunst ist, wenn man nichts mehr wegnehmen kann.
Die Philosophie von Unix ist "bottom-up". Aus einfachen, nicht weiter reduzierbaren Implementierungsblöcken setzt man immer größere Funktionalität zusammen.
- Es gibt genau ein System um beliebig lange Bytefolgen auf einer Festplatte zu speichern - Dateien.
- Es gibt genau ein System um Bytefolgen auf der Platte zu finden - Dateinamen.
- Verzeichnisse sind als Datei implementiert. Allerdings mit einer eindeutigen und zwingenden Interpretation durch das Betriebssystem.
- Symbolic Links sind als Datei implementiert. Ebenfalls, mit einer eindeutigen und zwingenden Interpretation.
Es spricht nichts dagegen, dass der Kernel am Ende des Dateinamens, etwa getrennt durch ein Sonderzeichen wie '\0' oder '/', den Mime-Type anhängt. Oder ein open(2) auf 'abc' als 'abc#data' implementiert (# ist hier das Sonderzeichen), und eine spezielle API bereitstellt um dann auf 'abc#mime-type' zuzugreifen (nichts anderes steckt hinter dem Konzept der 'Bundles').
Das eigentlich Problem steckt wo anders. - Zunächst verwenden KDE, GNOME, apache, pine, usw. alle eigene Interpretation/Implementierungen des Dateityps.
Selbst wenn es einen Systemaufruf file(2) - analog zu file(1) - gibt, müssten alle Anwendungen diesen auch verwenden. Wer schreibt das alles um?
-
Und dann ist nicht gewährleistet, dass das gewählte Dateityp-Konzept auch zukunftssicher und ausreichend ist. text/ascii mag ja ganz lustig sein. Aber text/ascii/crlf zur Unterscheidung von text/ascii/lf? Oder xml1.0-encoded-in-utf8? xml1.0-according-to-docbook-dtd-5.0?
Das Ziel des ganzen ist ja, dass der gewönliche DAU nur noch "da drauf klicken" muss, um zu arbeiten. Für mich klingt das nach Do-What-I-Mean. Und dies lässt sich in der Regel nur als Do-What-My-Admin-Told-You-To-Do implementieren. Und der kann wohl recht gut mit .txt leben. Oder halt .txt-for-stupid-boss, wenn er den File-Manager-For-Dummies auf s/\..*$// konfiguriert.
--
Ich bin ein Teletubby. Und das ist auch gut so.
|
|
|
|
|
|
| |
|
|
|
|
|
|
|
|
IHMO die KISS-Lösung (siehe auch oben: Directory-Aproach), abwärtskompatibel. Probleme: Geschwindigkeit und Speicherbedarf.
- als Bestandteil des Dateinamens im Inhaltsverzeichnis
relativ kompatibel, funnzt aber schlecht (siehe Artikel)
- als zusätzliche Einträge im Inhaltsverzeichnis (so macht es Microsoft bei den langen Dateinamen von Windows9X)
häßlich, inkompatibel mit Legacy-Tools (z.B. nach Systemcrash oder Metadaten mit shellskript manipulieren...)
- als eine zusätzliche Datei für alle Dateien (das Journal von ext3 ist so eine Sonder-Datei)
sicher der performanteste Ansatz. Probleme: aufwendig zu implementieren, Konsistenz, Legacy-apps
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Friday 07. December, 11:58 MET (#11)
|
|
|
|
|
Eine Möglichkeit hast du ausgelassen, und zwar, dass die Dateibesschreibung
an erster Stelle im Fileheader vor den Daten kommt. Ob sie gut ist,
will ich hier jetzt nicht entscheiden. Ich kann mich erinnern, dass man
zu den Files auf dem Amiga Kommentare dazuschreiben konnte. Das habe ich
unter Unix lange Zeit vermisst. Sinnvoll wäre, dass es prinzipiell möglich ist,
Daten in Strukturierter Form an Files dranzuhängen, die nicht gleich bei der
nächsten Kopie verschwinden. Sehr interresant wäre in dem Zusammenhang auch,
dass an einem File histories dranhängen, zb. wo sie herkommen, von welchem
Programm sie geschrieben worden, welcher User, ... und zwar, ohne, dass diese
Informationen durch einfache befehle wieder vernichtet werden können.
Naja
|
|
|
|
|
|
|
|
|
|
|
|
|
Urks - alaaalso das wird eine laengliche Antwort. Ich versuchs ma lauf die Reihe zu bekommen.
> [Bottum Up bei Unix, und das ach so simple System]
Bereits die Steinzeitanforderungen von Unix halten Metadaten im Filesystem - oder was sind Erstellungsdatum, Aenderungsdatum, Eigentuemer, Lese/Schreibrechte ?
Von der Reihnen Lehre her hat das alles im Filesystem nix verloren.
Symbolic Links:
Die werden bereits z.B. von ext2fs als 'eingebettete' Links unterstuetzt - zwechs performancegwinn. Links als Dateien zu implementieren ist ja auch nur ein schlimmer Hack. Auf der einen Seite erwartet man das Linsk vom OS transparent unterstuetzt werden auf der anderen implementiert man sie (dauerhaft) als Hacks ?
> [Arten der Implementation]
Zusaetzliche Dateien:
Damit ist warscheinlaich was analog der Verzeichnisidee gemeint - siehe meine anderen Bemerkungen dazu - grundsaetzlich aber machbar - ist nur irgendwie unschoen in meinen Augen.
Als Bestandteil das Dateinamens:
Pfui - das ist ja genau das was derzeit das Problem ist. Der Dateiname ist ein Information, und da rein sachen packen macht nur probleme ... ich mein, warum haben eigentlich die Ur-Unixer nicht den Besitzer in den Dateinamen verpackt, sondern diese Metainfo in ein eigenes Feld des Verzeichniseintrags gepackt ???
Zusaetzliche Verzeichniseintraege um Infos zu speichern:
AAAAAAAAAAAAAAAAAAAAAAAArgh ... das ist das schlimmste was ich mir so denken kann. Ist nur dann (der einzig) gangbare weg wenn man ein kontrolliertes Format mit festen laengen hat, wo eine konforme Erweiterung unmoeglich ist. Schoen, aber genau das ist bei ext2fs z.B. nicht der Fall - hier wurde von anfang an darauf geachtet das die Verzeichniseintraege erweiterbar sind - die sind naemlich schon sowas wie eine Sammlung von Metatags.
EINE zusaetzliche Datei:
So wie bei OS/2 EAs auf FAT Partitions ? ist m.E. ein besserer Notbehelft als die Verzeichniseintraege zu verhunzen (ala Microsoft)
Daten innerhalb der Blockkette der 'normalen' datei abspeichern:
Nette Idee, nur dann knirscht es garantiert beim zugriff von ausserhalb (nicht ueber MetaFS). Des weiteren muss man den Programmen ja die Dateien (inkl. atributen wie fileposition und laenge) so praesentieren als wenn die Metadaten nicht da waehren. Wenn dann kann das nur so gehen das die Metainformation HINTER den 'echten' Daten liegen ... aber auch das braucht einiges an manipulation - insbesondere macht es Probleme beim Dateierweitern etc.
Fuer mich kann es eigentlich nur eine Kombination sein:
a) EIne (vom OS unterstuetzte) Abstraktionsschicht zum Zugriff - so in der art wie:
int fmetaget(FILE *fd, char *buf, int buflen, char *metatag)
int fmetaset(FILE *fd, char *buf, int buflen, char *metatag)
int fmetarm(FILE *fd, char *metatag)
b) Eine Umsetzung entweder 'native' durch das jeweilige FS, oder durch eine 'fremde' Implementierung in einer Datei. Die Fremdimplementation (als EINE Datei) wuerde immer dann verwendet wenn das jeweilige FS die Metatags nicht native unterstuetzt. Bei ext2fs waere das Ganze 'native', in den Verzeichniseintraegen gespeichert.
c) Eine Emulation beim Zugriff auf Datenbestaende die ohne Metadaten erzeugt wurden.
d) Eine Libschicht die die Metadaten des MetaFS sowohl Gnome als auch KDE (und ggf. allen anderen) so praesentiert wie die Ihre Metadaten erwarten.
(Gerade im Hinblick auf d seh ich auch die chance mit einem 'neuen' MetaFS Land zu finden - um den gerade entstehenden Wildwuchs zu verringern)
Nun zu deinen Problemen:
> Wer schreibt das alles um.
Ich denke mal das ist das kleinste Problem - wenn die Loesung brauchbar ist, so kann udn wird sie sich durchsetzen (ich selbst wuerde mir nur den Apache vornehmen .... mein Problemkind :) Aber siehe d - Gerade das Uebernehmen ist ja eine Staerke im OS bereich - und an den immer wieder aufkommenden Diskusionen sieht man ja das das Loesungen gesucht werden.
> Dateitypkonzept zukunftssicher ?
Nun, zum einen denke ich das es das ist - das Metadatenkonzept wie es bei MIME verwendet wird hat sich als sehr stabil erwiesen - vieleicht nicht perfekt, aber stabil.
Zum anderen, es ist ja nicht daran gedacht alles in einen einzigen Wert zu packen. Zum einen der Content Type, welcher ja eine hirarchische Strukturierung erlaubt - um Dein beispiel mar etwas realer zu machen gibt es
text
text/plain
text/crlf
text/lf
Also einmal unbestimmten Text, dann einfacher Text und dann jeweils eine Variante fuer crlf und lf Formatierung. Der Zeichensatz hat da nix verloren, sondern wird durch einen charset= parameter hinten angehaengt
text/crlf; charset=CP1251
z.B. fuer eine Windooftextdatei. Oder
Content-type: text/plain; charset=us-ascii
fuer eine reine Asciidatei.
Dann geht es natuerlich auch weitere Untergliederungen zu nehmen:
application/ms-word/2.0
fuer eine Datei im Word 2.0 Format (Achtung, es geht nicht um den Ersteller, sondern um das Dateiformat!)
Ausserdem kann man hier durchaus auch andere, weitere Metadaten nehmen, wie es ja auch fuer Ersteller und Bearbeiter sinvoll ist (Der Mac kennt da nur den Ersteller) - Beispiel:
MetaFS-Creator: StarOffice/6.0
(Wobei ich mir dabbei auch sowas wie bei den Typen wuensche)
Ich schlag jetzt mal einfach MetaFS als teil des Namens vor - das haette den Vorteil das die Header nicht mit den MIME Typen kollidieren, und einwandfrei mit Mails (und HTTP) mittransportiert werden koennen...
... UND IST DA NICHT BEREITS EINE ELEGANTE MOEGLICHKEIT DANN AUCH BEIM DATENAUSTAUSCH DIE METADATEN ZU ERHALTEN ?
> Der Admin kanns ja konfigurieren. bzw. der Dau kann doch mit .txt leben
Richtig - aber mahl ehrlich, warum haben wir eigentlich die schoene Zeit der Lochkarten verlassen - zum einen konnte man damit praechtig leben, zum anderen gabs auch garkeine DAUs !
Davon ab, der Sinn ist ja das kein Admin irgendwas konfigurieren soll/muss - denk mal daran, im Desktopbereich gibts keine Admins - und Wenn Linux im Desktopbereich je was werden soll, dann nicht indem man den DAU zum Admin ausbildet.
Und sach jetzt nicht das Gnome/KDE ja konfigutrationen mitliefern die ja meist passen ... richtig, das ist aber genauso beschissen wie Microsofts Regestryloesungen ... sehr schoen, aber unflexibel und Fehleranfaellig.
Hmm ... hab schon lange nicht mehr so viel in FS dokumentationen rumgewuehlt wie in den letzten Tagen ... macht richtig Spass.
Gruss
H.
(Ich hoer mal besser auf)
|
|
|
|
|
|
|
|
|
|
|
|
|
- ...
- Symbolic Links sind als Datei implementiert. Ebenfalls, mit einer eindeutigen und zwingenden Interpretation.
- Dateien im MetaFS sind als Dateien im physical filesystem implementiert: Der erste Block der Datei im RealFS enthält die Anzahl der allozierten Metablöck und die ersten Metadaten. Die Nutzdaten folgen nach den Metadaten. Zwingende Interpretation der Datei durch das MetaFS:
- metafs.offset(datei) := realfs.blocksize * metafs.meta_info(datei).block_count
- metafs::stat(datei).st_size :=
realfs.stat(datei).st_size - metafs.offset(datei)
- metafs::seek(datei,offset,SEEK_SET) :=
realfs::seek(datei,metafs.offset(datei) + offset,SEEK_SET)
- ...
Es spricht nichts dagegen, dass der Kernel am Ende des Dateinamens, ....
Sorry, dann hast Du den Artikel nicht gelesen: Apple ging diesen Weg und hat auf diese Weise den Usern zu Hauf' Problem eingebrockt.
Zum Umschreibproblem: Wenn's filesystem rockt werden sich schnell Freiwillige finden, die die Apps patchen oder (z.b. für gnome-vfs2 oder apache) Module hacken. Sonst wäre's nicht OpenSource.
Von wegen Zukunftsicher: MIME handelt das Problem mit dem "encoding" Attribut: content-type text/plain; encoding=iso-8859-15. Bei der Erkennung des Zeilenumbruchzeichens wird 'n MetaFS wohl kaum helfen. Glaub' kaum, daß wir den binary-vs-text-File-Terror (open(file, "rt") vs
open(file, "r")) von Windows importieren wollen... Wie wäre es mit 'nem Filemanager, der für text/* 'ne Eintrag zum Konvertieren anbietet?
Oder beim Öffnen sich die Datei nach Zeilenumbrüchen scannt und ggf. nen Dialog zeigt:
=[ Erm... ]=====================
|
| Has'e wohl von 'nem DOZ-Luser, det File.
| Könnte deene Unix-App verwirren. Zu
| juttet altes Unix-Format konvatier'n?
nerven!
|
| [ Nö ] [ Yep ]
|
| [ ] Wag det nich' nochmal, mich damit zu +------------------------------------
PS: 'n ln-s, daß <pre> durchläßt wär' auch ganz cool...
|
|
|
|
|
|
|
