staging.inyokaproject.org

Max-Ulrich_Farber schrieb:

[…]

1. […]

2. […]

3. […]

4. Und wer damit noch nicht genug Arbeit hat, der kann ja gleich jetzt schon mit udisks2 anfangen…

5. […]

UDisks ist fertig.

Max-Ulrich_Farber schrieb:

1. Newubunti macht den Anfang und das "Einhängen" fertig und kümmert

Das kann ich übernehmen.

sich um die Hard- und Symlinks, weil ich davon nicht viel verstehe. UlfZibis ist ihm dabei sicher gerne behilflich.

Dazu fehlt mir die Praxis mit ntfs-3g. Ich bin über das Einhängen in den Artikel "gestolpert" und würde ungern darüber hinaus gehen.

LG, Newubunti

kB schrieb:

udisks ist fertig

Oh, ich schäme mich! Ich habe das gar nicht gemerkt. Aber ich habe zu dem Thema auch nicht viel zu sagen, dazu habe ich weder die nötigen Kenntnisse noch die Erfahrung.

Trotzdem will ich den Artikel ’mal studieren, das schadet mir nichts. Sieht ja wirklich gut aus!

@Newubunti:

Dazu fehlt mir die Praxis mit ntfs-3g. Ich bin über das Einhängen in den Artikel "gestolpert" und würde ungern darüber hinaus gehen.

Dann lassen wir das, und bei den Symlinks bleibt es bei der bisherigen, oberflächlichen Feststellung. Eigentlich reicht das ja auch für die Praxis.

Ich habe ’mal mit dem User-Mapping angefangen, bin aber damit noch nicht fertig. Auch der Abschnitt davor, die "Standard-Einstellungen" ist noch nicht ganz korrekt.

L.G.

Max-Ulrich_Farber schrieb:

[–] kümmert sich um die Hard- und Symlinks

"Hardlink" ist ein Synonym für Dateiname.

• Einen Hardlink anlegen bedeutet einer Datei einen weiteren Dateinamen zu geben. Natürlich sind dabei die geltenden Einschränkung für Dateinamen zu beachten.

• Alle Hardlinks/Dateinamen einer Datei sind gleichberechtigt.

• Wenn man den letzten Hardlink/Dateinamen zu einer Datei löscht, wird die Datei selbst gelöscht.

Vorstehendes gilt generell und gehört daher nicht in den Artikel zu ntfs-3g.

Speziell für NTFS als Dateisystemtyp gilt: Es unterstützt Hardlinks in dem Sinne, dass man einer Datei selbst mehrere Namen geben kann. Das ist nicht selbstverständlich, denn bei FAT und exFAT geht das z.B. nicht. Aber auch das ist nicht spezifisch für ntfs-3g und gehört damit nicht hier rein, sondern in den übergeordneten Artikel.

"Symlink" ist der Name für einen speziellen Dateityp. Hier ist auch wieder nur für den Dateisystemtyp NTFS festzustellen, dass dies grundsätzlich unterstützt wird, aber dies ist auch keine Besonderheit von ntfs-3g und gehört damit nicht in dessen Artikel, sondern in den übergeordneten.

Fazit: Solange es um den Artikel speziell zu ntfs-3g geht, darf man das Thema Hard- und Softlinks Symlinks getrost vergessen! Oder einfach auf den übergeordneten Artikel verweisen.

EDIT: Softlink → Symlink

kB schrieb:

Fazit: Solange es um den Artikel speziell zu ntfs-3g geht, darf man das Thema Hard- und Softlinks getrost vergessen!

Dass NTFS Hardlinks unterstützt, ist selbstverständlich. Ob ein Treiber solche auch setzen kann, nicht unbedingt.
Softlinks und Junctions werden von ntfs-3g auf eine ihm recht spezielle Art behandelt und zusätzlich von konfigurierbarem Volume-Mapping beeinflusst.

kB schrieb:

[…] Fazit: Solange es um den Artikel speziell zu ntfs-3g geht, darf man das Thema Hard- und Softlinks getrost vergessen!

Das sollte Symlinks heißen. Unter Linux werden Symlinks gelegentlich und unpräzise als Softlinks bezeichnet. Auch mir ist das leider passiert. Sorry.

Für die mit NTFS unter Windows verwendbaren Softlinks = Junctions gibt es unter Linux keine vergleichbare Funktionalität.

Dagegen funktionieren unter Windows angelegte Symlinks unter Windows wie gewohnt, aber nicht zuverlässig unter Linux; und unter Linux angelegte Symlinks funktionieren unter Linux wie gewohnt, aber nicht zuverlässig unter Windows. Und mehr muss m.E. nicht dazu gesagt werden.

Wer etwas über die Benutzung von Junctions (= Softlinks unter Windows, aber keine Symlinks) unter Linux schreiben möchte, mag das tun. Aus meiner Sicht gehört es nicht in den Artikel zu ntfs-3g, sondern in einen separaten Spezialartikel zum Spezialartikel.

Gibt es eigentlich eine Methode festzustellen, mit welchem Treiber eine NTFS-Partition bereits genutzt wurde?

LG, Newubunti

Max-Ulrich_Farber schrieb:

Ich habe ’mal mit dem User-Mapping angefangen, bin aber damit noch nicht fertig. Auch der Abschnitt davor, die "Standard-Einstellungen" ist noch nicht ganz korrekt.

Ich habe mit die letzte Änderung angeschaut und folgende Kommentare dazu:

Mehrere Verweise im Artikel funktionieren nicht, da hinter dem '#' ein Leerzeichen eingefügt wurde. Suche nach "[ #".

NTFS-3G geht den zweiten Weg.

Jain, denn auch der permissions-Weg entspricht dem "Tatbestand" "eigen, nur für Linux gültig" aus dem ersten Weg.

Da aber die Verwaltung von Besitz- und Zugriffsrechten in Windows anders strukturiert ist als in Linux, muss dafür deren Struktur in Linux auf diejenige in Windows abgebildet ("gemappt") werden. Das Verfahren nennt sich User-Mapping.

Auch permissions entspricht diesem Verfahren.

Die Termina "Default-User-Mapping" und default_user_mapping sollten IMHO vermieden werden, oder zumindest eindeutig definiert werden, was sie bedeuten. Sonst erscheint das dem Leser, als ob es neben permissions und acl noch eine dritte Variante mit entsprechender Option gäbe.

Statt ===''permissions''=== und ===''acl''=== besser ===`permissions`=== und ===`acl`=== verwenden.

Folgende Erklärung sollte IMHO in den Absatz ===`permissions`=== verschoben werden, und ohne Verwendung des Begriffs default_user_mapping, denn das Verfahren wird ja nicht per "default" angewendet, sondern erst aufgrund Aktivierung mit permissions.

Beim default_user_mapping werden dafür im Windows-System noch nicht verwendete SID verwendet. Mit diesen werden die Linux-Benutzer und -Gruppen als neue, namenlose, in Windows nur über ihre SID identifizierte Benutzer und Gruppen in die Windows-Rechteverwaltung übernommen.

Deshalb haben sie dort genau die Zugriffsrechte, die jeweils Anderen bzw. Jedem zugeteilt wurden.

Wenn ich nicht wüsste, wie es tatsächlich funktioniert, würde ich obigen Satz nie verstehen.

Üblicherweise sind dies Lese-, aber keine Schreibrechte.

Wo hast Du das denn her? Ist nicht meine Erfahrung. Nach meiner Erfahrung haben die Dateien im jeweils anderen System Lese- und Schreibrechte für Jeden.

Statt:

Weil beim default_user_mapping unabhängig von irgend einem Windows-System dem gleichen UID bzw. GID immer der gleiche SID zugeteilt wird, sind mit default_user_mapping erstellte Dateisysteme untereinander stets kompatibel.

finde ich das besser:

Weil bei permissions unabhängig von irgend einem Windows-System dem gleichen UID bzw. GID immer der gleiche jeweils passende SID zugeteilt wird, sind mit permissions erstellte Dateisysteme für Linux untereinander stets kompatibel.

Der Abschnitt ===Eigenschaften=== gehört doch nur unter ===`permissions`=== und nicht unter == Die Optionen ''permissions'' und ''acl'' == (auch hier besser: == Die Optionen `permissions` und `acl` ==). Und warum === ohne und == mit Leerzeichen abgrenzen?

Der Befehl

wmic useraccount get name,sid 

Wo hast Du das denn her, und wie soll das benutzt werden? Die Datei .NTFS-3G/UserMapping kann unter beiden Systemen mit einem gewöhnlichen Editor erstellt und bearbeitet werden. Anschließend ist es dann empfehlenswert, die Datei und den Ordner in Windows mit den Attributen "Versteckt", "System" und "Schreibgeschützt" zu versehen, damit der Windoof-Nutzer sie nicht versehentlich beschädigt.

kB schrieb:

Für die mit NTFS unter Windows verwendbaren Softlinks = Junctions gibt es unter Linux keine vergleichbare Funktionalität.

In Windows gibt es mindestens 4 Arten von Softlinks: "Verknüpfungen", "Junctions", echte "Sym-Links" und "Volume-Links". Letztere 3 werden von NTFS-3G "soweit wie möglich" richtig interpretiert und im Linux-Dateisystem als Symlinks dargestellt. Das "soweit wie möglich" lässt sich mit Anlegen von "Volume-Mapping" auf bis zu 100 % steigern.

Dagegen funktionieren unter Windows angelegte Symlinks unter Windows wie gewohnt, aber nicht zuverlässig unter Linux;

Richtig, siehe oben.

und unter Linux angelegte Symlinks funktionieren unter Linux wie gewohnt, aber nicht zuverlässig unter Windows.

Falsch. Sie funktionieren unter Windows nie. Genauer siehe: 9419814.

Wer etwas über die Benutzung von Junctions (= Softlinks unter Windows, aber keine Symlinks) unter Linux schreiben möchte, mag das tun.

Es muss nur erwähnt werden, dass sie ggf. in Symlinks "transformiert" werden, siehe oben.

Da ist jetzt wieder sehr viel beisammen. Ich arbeite das wieder "rückwärts" auf:

@UlfZibis:

Jain, denn auch der permissions-Weg entspricht dem "Tatbestand" "eigen, nur für Linux gültig" aus dem ersten Weg.

Du hast mich nicht richtig verstanden. Vielleicht habe ich mich auch schlecht ausgedrückt. "nur für Linux gültig" entsteht eben dadurch, dass die Benutzer Windows nicht namentlich bekannt sind. Aber der Weg ist trotz allem immer der zweite, und User-Mapping findet statt. Wenn du über das Terminal einbindest, bekommst du die Meldung:

~$ sudo mount -t ntfs-3g /dev/sdb1 /media/sdb1 -o defaults,permissions
[sudo] Passwort für farber: 
Using default user mapping
~$ sudo umount /media/sdb1
~$ sudo mount -t ntfs-3g /dev/sdb1 /media/sdb1 -o defaults,acl
Using default user mapping 

Auch permissions entspricht diesem Verfahren.

Eben. Ganz genau!

Statt ===permissions=== und ===acl=== besser ===permissions=== und ===acl=== verwenden.

Gerne. Über die Formatierung muss ich am Ende sowieso nochmal drüber gehen.

Folgende Erklärung sollte IMHO in den Absatz ===permissions=== verschoben werden, und ohne Verwendung des Begriffs default_user_mapping

Nun, der Begriff wird halt von NTFS-3G verwendet (s.o.). Und er gehört nicht zu permissions, denn er gilt genau so auch für acl.

Wenn ich nicht wüsste, wie es tatsächlich funktioniert, würde ich obigen Satz nie verstehen.

Wie funktioniert es denn deiner Meinung nach "tatsächlich"? IMO eben genau so, wie ich geschrieben habe.

Deshalb haben sie dort genau die Zugriffsrechte, die jeweils Anderen bzw. Jedem zugeteilt wurden.

Wo hast Du das denn her?

Du hast Recht, der Satz stimmt so nicht in beide Richtungen. In Linux sind die Benutzer unbekannt, deshalb hat dort jeder volle Rechte. In Windows sind die Besitzer zwar namenlos, aber über ihre SID bekannt. Da gilt der Satz. Sorry!

Weil bei permissions unabhängig von irgend einem Windows-System dem gleichen UID bzw. GID immer der gleiche jeweils passende SID zugeteilt wird, sind mit permissions erstellte Dateisysteme für Linux untereinander stets kompatibel.

Das gilt eben nicht nur für permissions, sondern auch für acl (s.o.), d.h. für jedes default_user_mapping (wie ich ja geschrieben hatte).

Der Befehl wmic useraccount get name,sid …

Das ist noch alt, so weit bin ich noch gar nicht. – Doch nebenbei: Der Befehl läuft unter Windows und ist sehr praktisch.

Zusammenfassung: Ich verstehe dich schon. Du würdest permissions gerne aus dem User-Mapping herauslösen. Aber das geht nicht. Die Verwaltung von Dateirechten funktioniert in NTFS-3G eben immer und ausschließlich über User-Mapping, ob man will oder nicht. In der früheren Fassung des Artikels kam dies nicht richtig zum Ausdruck.

L.G.

Newubunti schrieb:

Max-Ulrich_Farber schrieb:

1. Newubunti macht den Anfang und das "Einhängen" fertig und kümmert

Das kann ich übernehmen.

Done!

LG, Newubunti

Nun zum Thema Symlinks – Softlinks – Junctions – Hardlinks

Ich bin nach wie vor dafür, das Thema so kurz wie irgend möglich und nur oberflächlich zu behandeln. Sonst kommen wir schon wieder in die Hölle, und zwar unbarmherzig!

@kB:

Deine allgemeinen Ausführungen über Sym- und Hardlinks in Linux sind mir bekannt, und ich stimme diesen natürlich zu (sie stimmen ja auch…).

Fazit: Solange es um den Artikel speziell zu ntfs-3g geht, darf man das Thema Hard- und Softlinks Symlinks getrost vergessen! Oder einfach auf den übergeordneten Artikel verweisen.

Dem stimme ich fast zu, aber nicht ganz: Weil NTFS-3G und NTFS3 hier Unterschiede machen, ist zumindest ein entsprechender Hinweis nötig.

@UlfZibis

Softlinks und Junctions werden von ntfs-3g auf eine ihm recht spezielle Art behandelt und zusätzlich von konfigurierbarem Volume-Mapping beeinflusst.

Eben, das ist der Haupteingang zur oben genannten Hölle! Ich weiß, dass es das Volume-Mapping gibt, aber das würde ich ganz gerne verschweigen, weil man es AFAIK nur in diesem Zusammenhang, auf den ich lieber gar nicht eingehen möchte, braucht, und zwar nur für systemübergreifende Links. Mein Tipp: Weglassen!! Es gibt noch mehr bei NTFS-3G, auf das wir lieber hier nicht eingehen sollten.

Das Wiki ist IMO nicht dazu da, dass wir unbedingt alles, was wir wissen, darin auch anbringen müssen!

Newubunti fragt:

Gibt es eigentlich eine Methode festzustellen, mit welchem Treiber eine NTFS-Partition bereits genutzt wurde?

Gute Frage! – Eine sichere Methode kenne ich nicht. Aber ich weiß wenigstens ein paar "äußerst verdächtige" Spuren:

• NTFS-3G ohne User-Mapping: Wenn keine Dateien neu angelegt wurden, gibt es auch keine Spuren. Neu angelegte Dateien haben in Windows keine SID, sind also als solche verdächtig. Aber sie können auch von NTFS3 stammen.

• NTFS-3G mit Default User-Mapping hinterlässt in Windows namenlose Benutzer mit SID und ACL. Entdeckt man in Windows solche (z.B. mit wmic useraccount get name,sid ), so ist der Ursprung klar, denn NTFS3 tut das nicht.

• NTFS-3G mit vollständigem User-Mapping (d.h. alle Linux-User sind erfasst) hinterlässt in Windows keine namenlosen Benutzer und damit auch keine Spuren. Es gibt eben nur die Windows-Benutzer und ihre SID und ACL.

• Wenn in Windows seltsame, nicht oder falsch interpretierbare ACL auftauchen, fällt der Verdacht auf NTFS-3G. Aber das kann und sollte man ja vermeiden, wenn man aufpasst.

• NTFS3 hinterlässt, wenn dort Dateien neu angelegt wurden, in Windows u.U. auch Dateien ohne SID. Aber die können auch von NTFS-3G ohne User-Mapping stammen.

• NTFS3 hat in der Partition ein eigenes Rechtesystem angelegt (aber frage mich bitte nicht wie!) und hinterlässt damit sicher Spuren. Doch wie man die findet, weiß ich nicht.

L.G.

Max-Ulrich_Farber schrieb:

Jain, denn auch der permissions-Weg entspricht dem "Tatbestand" "eigen, nur für Linux gültig" aus dem ersten Weg.

Du hast mich nicht richtig verstanden. Vielleicht habe ich mich auch schlecht ausgedrückt. "nur für Linux gültig" entsteht eben dadurch, dass die Benutzer Windows nicht namentlich bekannt sind. Aber der Weg ist trotz allem immer der zweite,

Ja im Prinzip richtig, ich dachte nur, man könnte es evtl. falsch verstehen.

und User-Mapping findet statt. Wenn du über das Terminal einbindest, bekommst du die Meldung:

Using default user mapping 

Ja da meinen die wohl "default" bzgl. der Optionen permissions und acl, aber das ist doch nicht "default out of the box".

und ohne Verwendung des Begriffs default_user_mapping

Nun, der Begriff wird halt von NTFS-3G verwendet (s.o.). Und er gehört nicht zu permissions, denn er gilt genau so auch für acl.

Der Begriff könnte aber auch mit dem Verfahren von NTFS3 als vergleichbar angesehen und verwechselt werden, wo das Mapping ja tatsächlich per default stattfindet. Also wie gesagt, wenn Du den unbedingt verwenden willst, dann definiere ihn bitte ganz genau im Artikel.

Wie funktioniert es denn deiner Meinung nach "tatsächlich"? IMO eben genau so, wie ich geschrieben habe.

Deshalb haben sie dort genau die Zugriffsrechte, die jeweils Anderen bzw. Jedem zugeteilt wurden.

Soweit ich es verstanden habe, haben im anderen System dann alle Schreib- und Lese-Zugriff, also "volle Rechte" für "Jeder" in Windows und rwxrwxrwx auf Besitzer root unter Linux.

Weil bei permissions unabhängig von irgend einem Windows-System dem gleichen UID bzw. GID immer der gleiche jeweils passende SID zugeteilt wird, sind mit permissions erstellte Dateisysteme für Linux untereinander stets kompatibel.

Das gilt eben nicht nur für permissions, sondern auch für acl (s.o.),

OK, dann halt noch "bzw. acl" ergänzen.

Zusammenfassung: Ich verstehe dich schon. Du würdest permissions gerne aus dem User-Mapping herauslösen. Aber das geht nicht. Die Verwaltung von Dateirechten funktioniert in NTFS-3G eben immer und ausschließlich über User-Mapping, ob man will oder nicht. In der früheren Fassung des Artikels kam dies nicht richtig zum Ausdruck.

OK, dann mein Vorschlag (ganz grob):

Max-Ulrich_Farber schrieb:

Nun zum Thema Symlinks – Softlinks – Junctions – Hardlinks

Ich bin nach wie vor dafür, das Thema so kurz wie irgend möglich und nur oberflächlich zu behandeln.

Einverstanden, aber es sollte da nix falsches stehen.
Und für "Siehe auch Volume-Mapping 🇺🇸 " ist sicher auch noch Platz. Schließlich ist das ja auch eine der herausragenden Fähigkeiten von NTFS-3G.

Dem stimme ich fast zu, aber nicht ganz: Weil NTFS-3G und NTFS3 hier Unterschiede machen, ist zumindest ein entsprechender Hinweis nötig.

👍

Max-Ulrich_Farber schrieb:

[…]

Fazit: Solange es um den Artikel speziell zu ntfs-3g geht, darf man das Thema Hard- und Softlinks Symlinks getrost vergessen! Oder einfach auf den übergeordneten Artikel verweisen.

Dem stimme ich fast zu, aber nicht ganz: Weil NTFS-3G und NTFS3 hier Unterschiede machen, ist zumindest ein entsprechender Hinweis nötig.

Ok, da läuft etwas wild! Ein unter Linux mit dem einen Treiber mit Standardmethode (ln -s) angelegter Symlink funktioniert nicht mit dem anderen Treiber. Gilt in beiden Richtungen.

Warum das so ist, darauf muss der Artikel nicht eingehen.