Ganymed Geschrieben 25. März 2004 Geschrieben 25. März 2004 Hallo zusammen, eigentlich ist es ja eine Unix-Mac Kombi Frage, aber da das Problem auf dem Mac auftaucht, poste ich es mal hier hinnein. Wir hatten hier schon öfters die Situtation, dass wir hier das Unix-Rechte System am Mac nicht so ganz durchschaut haben... Ich poste mal ein paar Beispiele um zu verdeutlichen, was ich hier meine 1) Ich habe 2 Dateien. Diese möchte ich auf einen Server kopieren, welcher auf Unix aufgesetzt ist. Wenn ich die Dateien dort in einen Ordner (egal welchen) hineinziehe (per Drag n Drop), dann zeigt mir der Mac die Fehlermeldung "Datei konnte nicht kopiert werden, da ein Unbekannter Fehler aufgetreten ist". Die Dateien sind nicht mehr geöffnet und auch sonst nicht in irgendeiner Bearbeitung. Sie sind nicht geschützt. Mit einem Blick mit Hilfe von Apfel+I sehe ich, dass der User XYZ diesen Ordner für sich gepachtet hat. Also mounte ich das Laufwerk erneut, melde mich mit User XYZ an. Ich kann immer noch keine Dateien in den Ordner kopieren. Witzigerweise kann ich aber die Dateien in die oberste Ebene des Serves kopieren. (Obwohl alles auf den User XYZ ausgerichtet ist). Die Dateien lassen sich auch nicht in einen anderen Ordner vom Server aus verschieben. Erst mit einem FTP-Programm von Windows aus, kann ich die Dateien in meinen gewünschten Ordner verschieben... Wieso ging das nicht?!?!?! :confused: :confused: 2) Wir möchten gepackte Dateien auf einen Server stellen und von dort aus verschicken. Wir sehen, dass wenn wir die Datei mit einer Unix-Kiste auf das Format *.tar.gz packen, dass wir die Dateien nicht mehr auf dem Mac auspacken können. Anstatt einfach den Ursprungsordner mit den Ursprungsdateien herzustellen, erzeugt mir Stuffit 2 Ordner, einen mit jede Menge "******" drin, einen mit dem Ursprungsnamen und eine weitere kryptische Datei, die man nicht öffnen kann. Die Ordner sind leer und das entpackte ist 0KB groß. Wenn wir das tar.gz per Hand auf dem Terminal entpacken, dann Funktioniert das anstandslos. (Können wir aber dem Empfänger nicht zumuten). Erstes Kurisorium... :confused: (Warum geht das nicht mit Stuffit?) Dabei fällt uns noch etwas auf: die (mit der Hand) entpackten Dateien haben keine Previews mehr; d.h. Photoshopdateien werden als Default-Image angezeigt und eine QuarkXPress Datei hat auch kein Icon mehr (graues Icon) und lässt sich nicht mehr mit Quark öffnen... Also: Datei unbrauchbar. Die Bildateien kann man retten, in dem man diese neu aufmacht und neu absichert. Auch unzumutbar für den Empfänger. Zweites Kurisorium... :confused: :confused: (Wieso sind die Dateien unbrauchbar?) Um der Sache auf den Grund zu gehen, haben wir folgendes gemacht. Wir haben die Dateien nicht mehr gezippt, sondern nur ein *.tar File daraus gemacht. Das stellt die Dateien ja einfach zusammen... Gleiches Ergebnis. Dann wollten wir die Dateien einfach nur kopieren, um zu sehen, wann die Dateien unbrauchbar werden... Tja und jetzt kommt wieder das Rechtesystem ins Spiel. Dejenige, der die Sachen auf den Server (mit Unix) erstellt hatte, konnte die Dateien sehen, wir auf unserem Mac nicht. Einfach leer der Ordner. Nichts zu sehen. Obwohl die Dateien bei dem anderen auf dem Unix Rechner zu sehen waren und er uns auch Rechte für die Dateien vergeben hatte! Wie kann das denn gehen??? :confused: :confused: Kennt ihr auch diese komischen Rechtevergaben? Vielleicht auch nebenbei dieses Dateien-sind-auf-einmal-unbrauchbar-Problem? Kann man sich im Internet darüber bzgl. eines Rechtessytems von MacOSX (kein Panther Update) informieren? Bei google und Apple hab ich leider nichts gefunden... Ihr wärt echt eine grosse Hilfe. Die Zeit die dafür jedesmal drauf geht, wenn man NUR 2 Dateien verschieben will ist wirklich immens hoch... Gruss Ganymed Zitieren
Schlaubi Geschrieben 25. März 2004 Geschrieben 25. März 2004 Hallo, das hat nichts (glaub ich) mit dem Rechten zu tun...ich denke eher du hast es hier mit einem Problem der verschiedenen AppleTalk Protokollen und Produkten bzw. der Dateiablage zu tun.... Hier mal kurz die Unterschiede: Helios EtherShare Data Fork (Datei selber) wird im jeweiligen Ordner abgelegt Resource Fork wird im Unterordner ".rsrc" des Ordners abgelegt. Der Name ist mit dem Dateinamen identisch. Bei Helios EtherShare enthält der Resource Fork auch noch eine File-ID, die wiederum in der Desktop Datenbank eingetragen wird. über diese FileID, ist das File eindeutig zu identifizieren. So funktionieren Aliase von Ordnern auf dem Server z.B. auch dann, wenn der Ordner umbenannt worden ist. Eine Reparatur der Desktop Datenbank ist im laufenden Betrieb mit rebuild -n möglich. Mit rebuild -s werden Diskrepanzen in der Datenbank (falls vorhanden) angezeigt aber es wird nicht repariert. Für die Verwaltung der User, verwendet EtherShare die afppasswd (falls vorhanden) ansonsten werden die Systemuser benutzt. Es ist möglich Dateien, die sich nur durch Groß- und Kleinschreibung unterscheiden, auf dieselbe Ebene zu speichern. Einen Ordner, der solche Dateien enthält, kann man dann nicht vollständig auf einen Mac kopieren (oder vom Mac aus brennen), da der Mac den Vorgang abbricht, wenn er auf die 2te Datei "desselben" Namens stößt. Netatalk Data Fork (Datei selber) wird im jeweiligen Ordner abgelegt Resource Fork wird im Unterordner ".AppleDouble" des Ordners abgelegt. Der Name ist mit dem Dateinamen identisch. Der Resource Fork wird 1:1 vom Mac aus übernommen. Es gibt keine File-ID. Heißt: Aliase laufen gerne mal woanders hin als für was sie angelegt wurden. Es werden die normalen Linux Userinformationen verwendet. Es ist möglich Dateien, die sich nur durch Groß- und Kleinschreibung unterscheiden, auf dieselbe Ebene zu speichern. Einen Ordner, der solche Dateien enthält, kann man dann nicht vollständig auf einen Mac kopieren (oder vom Mac aus brennen), da der Mac den Vorgang abbricht, wenn er auf die 2te Datei "desselben" Namens stößt. Samba (benutzt vom Mac aus - unter OS X) Data Fork (Datei selber) und Resource Fork werden in demselben Ordner abgelegt. Der Name des Resource Fork lautet: "._<Dateiname>. Der Resource Fork wird 1:1 vom Mac aus übernommen. Es gibt keine File-ID. Aliase laufen daher ins Leere (finden ihr Ziel nicht mehr), wenn der Ordner oder die Datei auf dem Sambavolume umbenannt worden ist. Das ist auf jeden Fall besser als bei Netatalk, wo der Alias mal gerne einfach fehlläuft. Die Samba User werden über die smbpasswd verwaltet. Bei Samba ist es vom Mac aus NICHT möglich, Dateien, die sich nur durch Groß- und Kleinschreibung unterscheiden, auf dieselbe Ebene zu speichern. Aus dem Grund entfällt hier das "Zurück-Kopier-Problem", welches man bei NetAtalk oder Helios hat. Als Vergleich Bei Mac OS X und auch 9 werden (sofern HFS+ verwendet wird) Data und Resource Fork in eine Datei abgelegt. Das geht durch die Eigenschaft des HFS FileSystems. Weiterhin verwendet Mac OS auch File-ID's, um Dateien selbst dann wiederzufinden, wenn sie umbenannt worden sind. Solange man HFS verwendet, kann man (zumindest über den Finder) keine Dateien auf dieselbe Ebene speichern, die sich nur durch Groß- und Kleinschreibung unterscheiden. Wenn man bei OS X den Schritt auf ufs macht, verabschiedet man sich automatisch von den Resource Forks. Dafür kann man dann aber Case Sensitive, wieder jeder richtige Unix Rechner. Hoffe das hilft dir erstmal weiter...? Zitieren
Ganymed Geschrieben 25. März 2004 Autor Geschrieben 25. März 2004 Hey Schlaubi, du machst ja deinem Namen alle Ehre :uli :uli für diese ausführliche Antwort! Heisst das im Klartext, dass sich die beiden System trotz Unix nicht verstehen? Es liegt also quasi am "Dateiverständnis"? Wie kann man denn da einen gemeinsamen Nenner finden? Geht das überhaupt? Zitieren
Empfohlene Beiträge
Dein Kommentar
Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.