Hallo,

ich muss eine gewisse Datenmenge (viele kleine Dateien) von einem Helios-Server auf eine Windows-Freigabe verschieben. Wie erledige ich dies am besten?

1. Wenn ich über den Mac (Ethershare) kopiere habe ich viele Abbrüche wegen Rechten oder Problemen mit Groß- und Kleinschreibung. Schreibtischdatei ist frisch aufgebaut.

Frage hier: Gibt es ein Programm, dass den Kopiervorgang dokumentiert und fortsetzt bei Fehlern?

2. Macht es Sinn, die Daten über den PC (PCShare) zu verschieben?

3. Für ein zukünftiges arbeiten auf derm Windows-Freigabe mit einem Mac überlege ich Blueharvest einzusetzen, um die ._-Dateien nicht mehr zu haben.

Vielen Dank für Eure Hilfe.
Gruß Daniel

Hallo Daniel.
Mein Vorschlag: Das ganze auf dem Helios-Server tar-en und ggf. dann zip-en. Dabei kannst Du ja die ._-Dateien ausschliessen.

ist 3. eine Frage? ;-)

Hi,

Antwort auf [ Daniel Richter ]

ich muss eine gewisse Datenmenge (viele kleine Dateien) von einem Helios-Server auf eine Windows-Freigabe verschieben. Wie erledige ich dies am besten?

1. Wenn ich über den Mac (Ethershare) kopiere habe ich viele Abbrüche wegen Rechten oder Problemen mit Groß- und Kleinschreibung. Schreibtischdatei ist frisch aufgebaut.

Wie greift der Mac denn auf die Windows-Freigabe zu? Etwas per SMB? Falls ja, wenigstens DAVE im Einsatz?

Bzw. welche AFP-Server-Software kommt auf dem Windows-System zum Einsatz? ExtremeZ-IP oder MacServer IP?

Antwort auf:

Frage hier: Gibt es ein Programm, dass den Kopiervorgang dokumentiert und fortsetzt bei Fehlern?

Klar, gibt diverse Sync-Tools auch für den kleinen Geldbeutel oder für lau, die zumindest ein Log führen. Wird Dir aber auch nix bringen, wenn Probleme mit Groß-/Kleinschreibung auftreten, denn dann steht zu befürchten, daß das Zieldateisystem case-insensitive ist und damit nix mit "A.txt" und "a.txt" nebeneinander anfangen kann.

Antwort auf:

2. Macht es Sinn, die Daten über den PC (PCShare) zu verschieben?

Was ist denn das Ziel des Ganzen? Nur Dataforks von Interesse oder sollen am Ziel "vollwertige" Mac-Dateien (inkl. Custom Icons, ggf. Previews in der Resourcefork, etc.) entstehen?

Antwort auf:

3. Für ein zukünftiges arbeiten auf derm Windows-Freigabe mit einem Mac überlege ich Blueharvest einzusetzen, um die ._-Dateien nicht mehr zu haben.

Also doch plain-SMB vom Mac aus. OK, ich bin raus (die Resourceforks und Mac-Feinheiten auch). Mit sowas hab ich nix zu tun .

Gruss,

Thomas

Hi,

Antwort auf [ Coolio ]

Mein Vorschlag: Das ganze auf dem Helios-Server tar-en und ggf. dann zip-en. Dabei kannst Du ja die ._-Dateien ausschliessen.

Abgesehen davon, daß auf dem Weg eh keine "._"-Dateien entstehen (die erstellt das smbfs unter MacOS X automatisch, wenn Mac-Dateien auf dummen Dateisystemen wie FAT32, NFS oder auch SMB/CIFS gespeichert werden sollen), klappt sowas auch nur, wenn man Datei-/Ordnernamen verwendet, die den Gepflogenheiten von vor 30 Jahren genügen: plain-ASCII, also nicht mal Umlaute oder Sonderzeichen.

Es gibt Betriebe, in denen sowas noch vorkommen soll (bzw. Admins jeden morgen in ihre Don Quijote Rüstung steigen, um den sinn- und hirnlosen Kampf gegen ihre User und deren Umlaute und Sonderzeichen erneut aufzunehmen ).

Das Problem sind doch wie üblich die Encodings (auf 'nem Helios-Server ungleich MacOS X also UTF-8 precomposed mit Helios-Quotings, auf einem halbwegs aktuellen Windows-System UTF-16 Codepoints mit den typischen Windows-Beschränkungen -- keine Pipe, kein <, >, *, etc.)

Wenn man auf dem Server ein- und woanders wieder auspacken wollte, müsste man schon ein Tool nehmen, das damit umgehen kann (wie bspw. Helios' htar oder als netzwerk-taugliche Komponente bspw. Archiwares PresStore).

Aber ich halte ehrlich gesagt das ganze Unterfangen für zweifelhaft. Bzw. würde seitens Daniel gerne erstmal Details wissen, was überhaupt beabsichtigt ist.

Gruss,

Thomas

Guten Tag,

der Mac hat kein Dave im Einsatz und der Windows-Server auch nicht. Hier geht es um 10.6 auf eine SMB-Freigabe auf Windows.

Gruß Daniel

Antwort auf [ Daniel Richter ]

1. Wenn ich über den Mac (Ethershare) kopiere habe ich viele Abbrüche wegen Rechten oder Problemen mit Groß- und Kleinschreibung. Schreibtischdatei ist frisch aufgebaut.

Das Ziellaufwerk unterstützt nicht die Funktionalität des Quelllaufwerks. Da bringt auch ein Neuanlegen der Schrebtischdatei keine Abhilfe. Auf der Helios-Seite gibt es ja das schöne kostenlose Tool "Helios File System Test". Damit kann man die "Mac-Kompatibilität" der verschiedenen Server testen und sieht vielleicht welche Überraschungen noch bevorstehen.

Antwort auf [ Daniel Richter ]

2. Macht es Sinn, die Daten über den PC (PCShare) zu verschieben?

Ich würde zwischen verschiedenen Server-Produkten nur über einen Mac-Client (von mir aus auch mit einem Tool) kopieren, weil man ja nicht davon ausgehen kann, das unterschiedliche Produkte die Ressourcen gleich behandeln.

Antwort auf [ Daniel Richter ]

3. Für ein zukünftiges arbeiten auf derm Windows-Freigabe mit einem Mac überlege ich Blueharvest einzusetzen, um die ._-Dateien nicht mehr zu haben.

Ob das eine gute Idee ist? Sollte man auf jeden Fall vorher gründlich testen. Auszug aus dem FAQ des Herstellers:

Zitat

Can BlueHarvest cause data loss?
Yes. Some applications and file formats rely on data stored in ._ AppleDouble files (for example old MacOS fonts or EPS files). These files will be made unusable if their ._ AppleDouble file is deleted. Always make sure you use BlueHarvest with files which don’t rely on data in ._ AppleDouble files.

Nur als Anregung: Wenn man schon mal erlebt hat, dass Daten (z.B. Schriften) nach einer FTP-Übertragung unbrauchbar waren, dann werden diese Daten durch Punkt 2 und Punkt 3 auch zerstört.

Gruß
Andreas

File System Test, darauf hätte ich ja auch kommen können ;-) Danke.

Ergebnis von Winsows 2008 Server:

HELIOS File System Test
Version : 4.5.1

Test started at 15.03.2011, 9:48:14 Uhr
Selected Folder:
Test writing to data/resource fork: passed.
Test changing file permissions: permissions verify failed. Error = -1 (see above)
Test setting type/creator: passed.
Test file dates: attribute mod time error backup time error failed. Error = -1 (see above)
Test server copy file command: PBHCopyFileSync failed. Error = -50 error in parameter list
Test find file: PBCatSearchSync failed. Error = -50 error in parameter list
Test file/directory id consistency: passed.
Test file name with unicode chars: passed.
Test long file name: passed.
Testing save existing file: verify content of exchanged files failed. Error = -50 error in parameter list
Test large file support (4.1 GB): passed.


Ergenis von Helios:

Test started at 15.03.2011, 9:52:50 Uhr
Selected Folder: web2print
Test writing to data/resource fork: passed.
Test changing file permissions: permissions verify failed. Error = -1 (see above)
Test setting type/creator: passed.
Test file dates: attribute mod time error access time error failed. Error = -1 (see above)
Test server copy file command: passed.
Test find file:
expected 1, found 1 item in less than 1 seconds
expected >=1, found 100 items in less than 1 seconds
expected 0, found 0 items in less than 1 seconds
passed.
Test file/directory id consistency: passed.
Test file name with unicode chars: passed.
Test long file name: passed.
Testing save existing file: passed.
Test large file support (4.1 GB): passed.

Fehler bei "changing file permissions" und "file dates" kommt bestimmt vom Client. OS X 10.4 hat dies noch unterstützt. Die neueren OS X- Versionen erlauben diese Änderung auf dem Server nicht, wenn ich mich nicht irre.

Mich würde interessieren ob die Benutzer mit einem nicht funktionierenden "find file" leben können. Meiner Erfahrung nach will kein Macuser auf sein Apfel-F verzichten.

Da auf dem Helios-Server auch PCShare installiert ist, kann man einen schönen Test machen. Vom Mac auf einem großen Volume nach einer Datei suchen und die Zeit messen. Dann das Volume unmounten und über smb (PCShare) mounten und die selbe Suche durchführen, viele Tassen Kaffee trinken (je nach Anzahl der Dateien auf dem Volume) und die Zeit messen.

Denn nach der Ausgabe des "File System Test" wird eine Suche auf dem neuen Server, obwohl wahrscheinlich deutlich leistungsfähiger, um vieles langsamer. Und diese Suche ohne "find file" belastet auch schön den Server. Da werden die Admins den Usern bestimmt die "Apfel"- und "F"-Tasten aus der Tastatur reißen, denn viele parallele Suchen können sogar den Server lahm legen.

So genug Bekehrungsversuche.

Gruß
Andreas

Hallo Andreas,

es gibt keine Bekehrung. Ich muss die Daten liefern, da führt kein Weg vorbei und die Firma, die diese erhält, hat einen größeren Windows-Serverpark und wird sich für ca. 40 GB (aber dafür viele kb-Dateien Illustrator) nicht eine Zusatzlösung anschaffen. Die Frage ist halt nur, wie bekomme ich die Daten auf den Server. Ich hoffe, dass dann die Macs per SMB darauf arbeiten können.

Gruß Daniel

Hi

Ich verstehe die ganze Aufregung nicht so ganz.
Du musst viele kleine Dateien liefern die später auf einem Dir nicht bekannten Windows-Server für unbekannte Zwecke rumliegen?
Also warum nicht tar-en und abliefern?
Markus

Hi,

nur kurz...

Antwort auf [ Markus76 ]

Du musst viele kleine Dateien liefern die später auf einem Dir nicht bekannten Windows-Server für unbekannte Zwecke rumliegen?
Also warum nicht tar-en und abliefern?

Weil das Ergebnis evtl. was ist, mit dem niemand was anfangen kann?

Die Knackpunkte im Einzelnen:

- Dateinamen-Encoding: UTF-8 (de- oder precomposed je nach Plattform) auf dem Helios-Server (ein paar Zeichen immer speziell "gequoted" per Caret "^" gefolgt vom hexadezimalen Wert) vs. $irgendwas unter Windows je nach Zieldateisystem (aber vermutlich UTF-16/UCS-2)

- Finder-Metadaten (Etiketten, Attribute, etc.): Stecken unter Helios im .rsrc-Verzeichnis, unter Windows entweder in einem NTFS-Stream namens $AFP_AfpInfo (wenn die Dateien per AFP also per ExtremeZ-IP oder MacServer IP an Bord kamen oder via SMB, wenn DAVE auf den Macs installiert ist) oder in einem Teil der beliebten "._"-Dateien (AppleDouble kodierte Dateien, in denen Finder-Info und Resource Fork seitens MacOS X gesteckt werden), wenn die Dateien mit dem normalen SMB-Client von MacOS X per SMB auf den Windows-Server kopiert wurden.

- Resource Forks (da steckt ggf. alles drin, bspw. alte PostScript Type 1 Fonts, ggf. Nettigkeiten wie die Screen-Preview eines Mac-EPS, ggf. auch nur Redundantes). Dito wie für Finder-Metadaten, nur heißt der File-Stream dann eben $AFP_Resource anstatt $AFP_AfpInfo

Welches tar kann das dynamisch umsetzen? Nur das von Helios (htar). Das braucht's dann aber auch zum Auspacken unter Windows. Und das bringt dann mal gradraus nix, wenn dort auf dem Windows-Rechner später die Macs per SMB ohne DAVE zugreifen sollen. Denn dann steckt Mac-Spezifisches in File-Streams, die Clients erwarten es aber in den dann nicht existenten "._"-Dateien.

In dem Fall einzig andere Variante, wenn der Mac-Kram wirklich von Bedeutung ist: Man nimmt das allerfrischeste (von letztem Donnerstag) rsync von Mike Bombich auf einem Mac, mountet das Helios-Volume auf der einen Seite und den anderen Dateiserver direkt per SMB auf der anderen Seite und läßt rsync mit den richtigen Parametern werkeln. In dem Fall liefert Helios seine interne Repräsentation der Daten via AFP, rsync nimmt den Mac-Kram mit, und für die richtige Ablage in den "._"-Dateien sorgt dann das smb-VFS von MacOS X.

Einziger Show-Stopper in der Situation: evtl. auf den Helios-Volumes herumliegende ._-Dateien, an denen sich rsync verschlucken wird (die muß man dann vorher eben löschen, weil sind potentiell sowieso unwichtig). Achtung: Wenn die auf einem Helios-Volume liegen und dort per AFP hingekommen sind, dann enthalten die nur Extended Attributes. Der ganze Rest steckt in Helios' interner Repräsentation von Finder-Metadaten und Resourcefork (steckt also im .rsrc-Verzeichnis).

Man kann sich natürlich um all die Fallstricke nicht kümmern, weil man sich sagt: Dateinamen sind egal und den Mac-Kram braucht man eh nicht. Dann ist es in der Tat egal, wie die Dateien transferiert werden. Wenn allerdings am Zielort wieder Macs damit umgehen sollen (und man deshalb ggf. Relevantes in sowohl Finder-Metadaten als auch Resourceforks an Bord hat und die Dateinamen aller Wahrscheinlichkeit nach kunterbunt und nicht "plain ASCII" ausfallen), dann muß man sich paar Gedanken mehr machen -- siehe oben.

Wobei das Ziel -- Macs greifen per SMB auf Windows-Server zu -- keinen großen Spaß machen dürfte. Zumindest den Usern nicht.

Gruss,

Thomas

Hi Thomas!
Das ist schon klar.
Aber so wie ich es verstanden habe, weiß man nicht wer auf dem Zielvolume was mit den Dateien machen will bzw. um was für Dateien es denn konkret geht und ob all diese Faktoren überhaupt relevant sind.
Ich habe das Problem so verstanden: "Ich bekomme die Fülle an Daten nicht von A nach B".
Markus

Hallo Markus,

an B soll mit 2 Macs und 2 Usern mit den Daten normal weitergearbeitet werden.

@Thomas: Danke Thomas für deine immer wiederkehrenden kompetenten Antworten. Ich werde mich evtl. nochmal bei dir melden.

Gruß Daniel

Huch, da hab ich wohl was überlesen ;-)

Antwort auf [ Daniel Richter ]

an B soll mit 2 Macs und 2 Usern mit den Daten normal weitergearbeitet werden.

Dann würde ich versuchen, den dortigen Verantwortlichen klarmachen, daß sie wenigstens zwei DAVE-Lizenzen kaufen oder 'ne kleine MacServerIP- (weiß aber nicht, ob das noch weiterentwickelt wird) oder ExtremeZ-IP-Lizenz. In allen drei Fällen ist es nötig, die Finder-Metadaten und Resourcefork als NTFS-Filestreams am Ziel zu haben (d.h. mittels Helios' htar[exe] transferierbar).

Weiterer Vorteil: Die "._"-Dateien werden nicht vom Client angelegt, sondern alles Mac-Spezifische liegt in File-Streams, d.h.

a) unsichtbar von Windows aus

b) transparent gehandhabt von Windows aus (also wenn von PC-Kollegen Dateien verschoben werden, dann sind nicht plötzlich die Resourceforks/Metadaten futsch sondern kleben als Streams immer noch an der "Datafork")

Ist bisschen überholt, da bald 4 Jahre her: Aber damals hatte ich bei einem Kunden (mein erster mit Helios auf Windows) einen direkten Vergleich zwischen DAVE auf den Clients und ExtremeZ-IP: Letzteres brachte eine um ein Mehrfaches bessere Performance. Und angeblich ist SMB mit MacOS X Bordmitteln noch lahmer als DAVE (weiß ich allerdings nicht, weil ich das aufgrund der Fehlerträchtigkeit und der kaputten Mac-Dateizugriffssemantiken noch nie ernsthaft untersucht habe)

Antwort auf:

@Thomas: Danke Thomas für deine immer wiederkehrenden kompetenten Antworten. Ich werde mich evtl. nochmal bei dir melden.

Keine Ursache, hab's forenbedingt vorhin bisserl ausführlicher und generischer ausformuliert...

Gruss,

Thomas