Unter Gnome 2 hatte Nautilus noch unter Properties von Verzeichnissen und Dateien einen Reiter "Notes". In Gnome 3 ist dieser Reiter offenbar wegrationalisiert worden. Auch wenn die Implementierung ziemlich abenteuerlich war, fand ich diese Funktion sehr nützlich. Gibt es irgend ein Plugin o.ä., das diese Funktion unter Gnome 3 nachrüstet?
Taucher schrieb: > Unpraktikabel Taucher schrieb: > Auch wenn die Implementierung ziemlich abenteuerlich war, Ahja. Konnte man wenigstens irgendwo nach Ordnern mit den Notizen suchen? Sonst erschließt sich mir der Nutzen nicht. mfg mf
Kannst ja einen Bookmark setzen, und zwar auf eine Textdatei.
Achim M. schrieb: > Ahja. Konnte man wenigstens irgendwo nach Ordnern mit den Notizen > suchen? Nein, aber das Icon hatte ein Zeichen, dass eine Notiz da ist – das reicht nach meiner Erfahrung völlig für Quellangaben oder ähnliche Metainformation. Nach Inhalt suchen kann man mit grep & Co.
Die Dateiembleme in Gnome 2 waren klasse. Allerdings wurden die auch wegrationalisiert und sie hatten den großen Nachteil, dass die Metainformationen nicht mitkopiert wurden. Die Informationen konnten somit verloren gehen. So etwas gehört somit eigentlich in die Dateisysteme. Das BeFileSystem (BFS) hatte dafür erweiterte Dateiattribute für Metadaten, die man indexieren und wie bei einer Datenbank abfragen konnte. Bei NTFS wurden die erweiterten Attribute nur Stiefmütterlich umgesetzt und die alternativen Datenströme waren ein Sicherheitsrisiko. Tja und sobald man dann Dateien zwischen verschiedenen Dateisystemen hin und herkopiert, gehen die Informationen dann auch verloren. Ganz schlimm wird's mit FAT und seine FAT artigen Nachfolger. Heutzutage werden daher Krückenlösungen verwendet, bei dem die Metainformatikonen als Teil des Dateiformats direkt in die Datei gepackt wird. Das mag bei Bildern, wo man nur speichern möchte wie groß die Auflösung ist, noch ganz praktisch sein, aber schon bei einer PDF, wo sich der Leser bspw, nur merken will, wo er das letzte mal mit lesen aufgehört hat, wäre es schon fatal, wenn man dafür die PDF und somit die Prüfsummen ändern würde, nur um die Metainformation reinzuschreiben. Deswegen gehören Metainformationen oftmals nicht in das Dateiformat.
Nano schrieb: > und sie hatten den großen > Nachteil, dass die Metainformationen nicht mitkopiert wurden. Das meinte ich mit abenteuerlicher Implementierung. Unter Mate gibt es das alles ja noch und von dort weiß ich, wie die das gemacht haben: die Notes werden in den Extended Attributes der Datei gespeichert – die gibt es aber nicht auf allen Dateisystemen. Wobei das noch das kleinere Problem ist, denn die Burschen haben vergessen, die Extended Attributes mit zu kopieren, wenn die Datei kopiert wird. Man kann das aber mit dem passenden Programm zu Fuß nachholen… An Mate stören mich die seit Ewigkeiten nicht gefixten Probleme mit dem Workspace Switcher, die nach dem Umschalten auf einen anderen Workspace die Z-Reihenfolge der Fenster durcheinander bringen – man klickt dann in das oberste Fenster,und wundert sich, warum nichts passiert, denn der Klick kommt im darunter liegenden Fenster an – und falls ein modaler Dialog einer App offen ist, wird die auf den neuen Workspace mit geschleppt. Mir ist das mittlerweile dermaßen lästig, dass ich von Mate weg will. > Heutzutage werden daher Krückenlösungen verwendet, bei dem die > Metainformatikonen als Teil des Dateiformats direkt in die Datei gepackt > wird. Das ist keine Lösung. Diese Metainformationen, die man in den Notes abspeichert, haben in den Nutzdaten nichts verloren.
Taucher schrieb: > Unter Mate gibt es das alles ja noch und von dort weiß ich, wie die das > gemacht haben: die Notes werden in den Extended Attributes der Datei > gespeichert – die gibt es aber nicht auf allen Dateisystemen. Wobei das > noch das kleinere Problem ist, denn die Burschen haben vergessen, die > Extended Attributes mit zu kopieren, wenn die Datei kopiert wird. Die werden bei Gnome 2 und Mate nicht in Extendes Attribute der Datei gespeichert, sondern das sind schlichtweg extra Dateien die in einem anderen Ordner zusätzlich gespeichert werden. Siehe: https://stackoverflow.com/questions/10874702/gnome-where-does-nautilus-store-emblem-data-and-how Ein Programm, dass die Dateien kopiert, muss also auch diese extra Daten kopieren und wenn man ein Backup macht, muss man die entsprechenden Ordner sichern. > Man > kann das aber mit dem passenden Programm zu Fuß nachholen… Das ist dann eine Würgelösung. Das Problem hat man ja übrigens auch, wenn man cp auf der Konsole zum kopieren verwendet, denn dieses kopiert die extra Daten auch nicht. Das ganze ist schlichtweg nicht ordentlich integriert und deswegen hat man es wohl auch wieder fallen gelassen. Denn um das richtig zu machen, müssten alle Programme das berücksichtigen und extra Dateien anzulegen ist eben halt keine saubere Lösung, das gehört in die Extended Attribute des Dateisystems. Aber da hat man dann halt das Problem, dass man diese Daten nicht in jedem Dateisystem abbilden könnte und wenn doch, müsste man hier die Daten in den Extended Attributen auch noch unterschiedlich speichern. Auch der Posix Standard, an dem man sich bei Linux strikt, leider zu strikt hält, unterstützt das nicht und sieht das nicht vor. Und weil man den einhalten will, wird das wohl auch nie der cp Befehl lernen oder unterstützen. Deswegen wäre das, wenn, dann nur in völlig modernen Betriebssystemen integrierbar wo man sich an keine Altlasten und alten Standards mehr strikt hält. BeOS war hier ein Versuch, aber dem fehlen auch viele Funktionen, die man von einem modernen OS heutzutage erwarten würde. Da wären z.B. nur mal die in BeOS fehlende Multiuserfähigkeit und eine gut integrierte Mandatory Access List für eine strikte Prozesstrennung. Letztes ist bei einem Linux System übrigens auch nur aufgesetzt und somit ebenfalls ne Krückenlösung wie die Embleme bei Gnome 2 bzw. Mate, auch wenn es der Kernel integriert hat, aber es bringt halt nichts, wenn es im Userbereich eine Krückenlösung bleibt. > An Mate stören mich die seit Ewigkeiten nicht gefixten Probleme mit dem > Workspace Switcher, die nach dem Umschalten auf einen anderen Workspace > die Z-Reihenfolge der Fenster durcheinander bringen – man klickt dann in > das oberste Fenster,und wundert sich, warum nichts passiert, denn der > Klick kommt im darunter liegenden Fenster an – und falls ein modaler > Dialog einer App offen ist, wird die auf den neuen Workspace mit > geschleppt. Bugreportnummer? Das Problem an Mate ist heutzutage, dass es quasi nur noch "warm" gehalten wird. Als man mit Gnome 3 fertig war ist ja nur ein kleiner Teil nach Mate gewechselt und das sind wohl nicht genug oder es fehlt in diversen Bereich das Know How um alles zu fixen, deswegen tut sich da nichts. Ein anderer Teil ist zu XFCE gewechselt und da geblieben. > Mir ist das mittlerweile dermaßen lästig, dass ich von Mate weg will. Jeden Morgen, wenn ich meinen Rechner erstmals starte, vergisst KDE das Hintergrundbild auf dem zweiten Bildschirm und schiebt das des zweiten Bildschirms auf meinen ersten, während der zweite Bildschirm dann einen schwarzen Hintergrund bekommt. Dann muss ich mich nach dem anmelden einmal ausloggen und wieder einloggen, dann ist es wieder normal so wie gewünscht. D.H. beide Bildschirme bekommen den Hintergrund, den ich für sie eingerichtet habe. Woran das liegt? Keine Ahnung. Da ich aber Debian Stable verwende, habe ich halt immer die Hoffnung, dass das in einer der neueren KDE Versionen dann gefixt ist. Und nen Bugreport schreiben kann ich nicht, da die Leute bei KDE grundsätzlich alle Nutzeraccounts nach einiger Zeit der Nichtbenutzung löschen. Und jedes mal nen neuen anzulegen, darauf habe ich auch keine Lust. >> Heutzutage werden daher Krückenlösungen verwendet, bei dem die >> Metainformatikonen als Teil des Dateiformats direkt in die Datei gepackt >> wird. > > Das ist keine Lösung. Diese Metainformationen, die man in den Notes > abspeichert, haben in den Nutzdaten nichts verloren. Deswegen sag ich ja, Krückenlösung. Aber anders ist das auch nicht machbar, denn dazu müsste man den Posix Standard erweitern um da langfristig irgendetwas zu erreichen. Aber den rührt heutzutage auch keiner mehr an.
Nano schrieb: > Die werden bei Gnome 2 und Mate nicht in Extendes Attribute der Datei > gespeichert, sondern das sind schlichtweg extra Dateien die in einem > anderen Ordner zusätzlich gespeichert werden. Guck mal wie alt der Eintrag bei Stackoverflow ist… Ich habe beim Wechsel von Mint 17 auf Mint 19 auf einer neuen Platte die Notes von Mint 17 mitgenommen. Dabei hat mir netterweise jemand vom Mint-Team mit einem Skript geholfen, das die Notes bei Mint 17 aus den Extended Attributes fischt und in eine Textdatei schreibt und auf Mint 19 – mit einem anderen Programm! – wieder zurück. > Das ganze ist schlichtweg nicht ordentlich integriert und deswegen hat > man es wohl auch wieder fallen gelassen. Ich schrieb ja "abenteuerlich…".
Taucher schrieb: > Nano schrieb: >> Die werden bei Gnome 2 und Mate nicht in Extendes Attribute der Datei >> gespeichert, sondern das sind schlichtweg extra Dateien die in einem >> anderen Ordner zusätzlich gespeichert werden. > > Guck mal wie alt der Eintrag bei Stackoverflow ist… Die Codebasis ist im großen und ganzen dieselbe. Mate ist ein Fork von Gnome 2 und wenn, dann wird man höchstens das Verzeichnis geändert haben, aber ich glaube nicht, dass man so große Änderungen am Code vorgenommen hat, dass jetzt die Extended Attribute verwendet werden. Das wäre auch nicht Zielführend, da Mate ein Desktop ist, der auch auf anderen Betriebssystemen außer Linux funktionieren soll. Man denke da nur mal an OpenBSD und die Leute haben schlichtweg gar keine Extendes Attributes implementiert: https://en.wikipedia.org/wiki/Extended_file_attributes#OpenBSD Und das wird dann wohl auch der Grund sein, warum man das damals bei Gnome 2 in ganz normale Dateien speicherte. Und alle Desktop Environments die sich an das FreeDesktop Projekt halten, legen thumbnails von Bildern im .thumbnail Ordner ab, anstatt die Thumbnails in den Extendes Attributen der Dateien zu speichern. Bei ext4 ist der Speicherplatz zudem auf nur 4 KB für Extendes Attribute begrenzt. Im Grunde ist BeOS und sein Open Source Nachfolger Haiku das einzige OS, dass diese Funktion wirklich auch bis auf Userspaceebene also Programmebene ausnutzt. Thumbnails werden dort AFAIK in den Extended Attributen gespeichert. Bei allen anderen Betriebssystemen, wirkt es recht aufgesetzt. Ob Mac OS X oder Windows, bei allen ist es genauso halbherzig. Und sobald man die Daten übers Netzwerk kopieren will ist Schicht im Schacht. > Ich habe beim Wechsel von Mint 17 auf Mint 19 auf einer neuen Platte die > Notes von Mint 17 mitgenommen. Dabei hat mir netterweise jemand vom > Mint-Team mit einem Skript geholfen, das die Notes bei Mint 17 aus den > Extended Attributes fischt und in eine Textdatei schreibt und auf Mint > 19 – mit einem anderen Programm! – wieder zurück. Dann guck dir das Skript an, ob es die Daten wirklich aus den Extended Attributes holt und nicht aus einem Verzeichnis.
@Taucher Apropo Netzwerk, es gibt für NFSv4 einen Vorschlag in Form eines Request for Comment die Unterstützung von Extended Attributen in NFSv4 zu implementieren. Geschehen ist bis jetzt noch nichts, der RFC ist aber trotzdem interessant, falls es dich interessiert, da er genau das heutige Problem beschreibt. https://tools.ietf.org/html/rfc8276 Immer mehr Leute verwenden ein NAS um ihre Daten aus dem Arbeitsrechner auszulagern und zu verwalten. Und solange die Netzwerkprotokolle nicht alle sauber und standardisiert die Extended Attribute kopieren können, wird kein Desktop Environment solche Sachen in den Extendes Attributen speichern wollen.
Nano schrieb: > Taucher schrieb: > > Dann guck dir das Skript an, ob es die Daten wirklich aus den Extended > Attributes holt und nicht aus einem Verzeichnis. ~das war eine Datei im Heimatbaum ;) https://en.wikipedia.org/wiki/GVfs https://askubuntu.com/questions/14669/are-file-notes-exclusive-to-nautilus-is-there-a-terminal-cli
Nano schrieb: > Mate ist ein Fork von Gnome 2 und wenn, dann wird man höchstens > das Verzeichnis geändert haben, aber ich glaube nicht, dass > man so große Änderungen am Code vorgenommen hat, dass jetzt die Extended > Attribute verwendet werden. Bei Mint ist ist es mindestens seit der 17 definitiv so. Das Skript, das ich mir mit den Infos vom Mint-Team gebaut hatte, ist im Anhang.
Taucher schrieb: > Nano schrieb: >> Mate ist ein Fork von Gnome 2 und wenn, dann wird man höchstens >> das Verzeichnis geändert haben, aber ich glaube nicht, dass >> man so große Änderungen am Code vorgenommen hat, dass jetzt die Extended >> Attribute verwendet werden. > > Bei Mint ist ist es mindestens seit der 17 definitiv so. Das Skript, das > ich mir mit den Infos vom Mint-Team gebaut hatte, ist im Anhang. Das Skript verwendet einen Befehl von GVfs. Genaugenommen gvfs-info. https://www.commandlinux.com/man-page/man1/gvfs-info.1.html Lies dir den bereits von avater oben verlinkten WP Artikel durch. https://en.wikipedia.org/wiki/GVfs Es handelt sich hier also nicht um Extended Attribute des Dateisystems, sondern um Daten die in normalen Dateien von GVfs abgelegt werden. GVfs ist ein virtuelles Dateisystem, also kein echtes, sondern eine Softwareschicht die nach Außen für Programme die GVfs nutzen ein Dateisystem abbildet. Die Daten werden dann aber ganz normal in Dateien gespeichert. Siehe dazu der erste Link, den ich dir ganz oben schon zum Thema gepostet habe.
war gerade getippt, der proxy wurde aber verweigert :( hast es ja schon geschrieben,sehe das auch so --- Wohl aber keine Atribute des eigentlichen Filesystems keine xattribs eines extFS sondern des darüberliegenden gnome gvfs/gio. ~/.local/share/gvfs-metadata/ hol doch ein Terminal lese die xattribs einer Datei direkt das skript bemüht gvfs-info das liest aus ~/.local/share/gvfs-metadata/ u. gio set, k.A. wo das jetzt hingeht.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.