NetaTalk/Samba mit iPhoto (AlbumData.xml)

30/01/2008 - 13:01 von Andreas Boeckler | Report spam
Hallo,

hat jemand erfolgreich seine iPhoto-Library auf ein Share mit diesen
beiden Protokollen gespielt und dann auch benutzt?

iPhoto beschwert sich in beiden Varianten über AlbumData.xml [1]:
Could not move new AlbumData.xml file into proper place; error: 0

Der Server làuft auf FreeBSD. Über NFS gibt es das Problem nicht. Dies
ist jedoch keine Option, da die Freigabe auf einem FW400-Laufwerk liegt,
dass von FreeBSD und Leopard les- und schreibar sein muss (VFAT).[2]

Zur Zeit behelfe ich mir mit Symlinks von Originals und Modified auf die
Freigabe/Mountpoint (/Volumes/SHARE), aber die Lösung find ich nicht so
prickelnd.

bye

Boecko

[1] http://discussions.apple.com/messag...89#6463089
[2] http://www.bsdforen.de/showthread.php?t 349
 

Lesen sie die antworten

#1 Thomas Kaiser
30/01/2008 - 20:25 | Warnen spam
Andreas Boeckler schrieb in <news:fnpou8$jj6$
hat jemand erfolgreich seine iPhoto-Library auf ein Share mit diesen
beiden Protokollen gespielt und dann auch benutzt?



Wer "beide Protokolle" parallel nutzt, sollte darauf achten, daß er nur
Plain ASCII für Dateinamen nutzt (keine Ahnung, was iPhoto da für
Vorstellungen hat) und daß er tunlichst nach jedem Schreibvorgang per
NFS seine CNID-Datenbanken (.AppleDB) wegschmeißt, weil das zu ID-
Inkonsistenzen bei Netatalk führt. Einfach mal in die Doku und die FAQ
zu Netatalk schauen, da steht das alles beschrieben.

ist jedoch keine Option, da die Freigabe auf einem FW400-Laufwerk liegt,
dass von FreeBSD und Leopard les- und schreibar sein muss (VFAT).[2]



Au weia, das auch noch. MacOS X schreibt dann auf die externe Platte in
irgendeinem Encoding (keine Ahnung, was das passende VFS da nimmt) und
schreibt Metadaten in einer AppleDouble v2 Verballhornung (Metadaten und
Resourceforks in Dateien, deren Name mit "._" beginnt) neben die
eigentliche Datei (bzw. die reine Datafork).

Per NFS würde die selbe AppleDouble-Repràsentation benutzt ("._"-
Dateien) aber als Encoding dann UTF-8 decomposed (also wieder brav
"plain ASCII" nutzen sonst Trouble).

Per AFP müsstest Du den afpd in den idiotischten aller Modi zwingen
(adouble:osx -- siehe Kommentare in der Manual page dazu) und dito das
serverseitige Encoding von UTF-8 precomposed (default) ebenfalls auf
UTF-8 decomposed stellen. Nur wird der afpd wegen der adouble:osx Option
dann nicht mehr so richtig sauber arbeiten. Und wenn Du den default
adouble:v2 nutzt, dann kriegst Du Metadaten- und Resource-Fork-Salat.

Mit anderen Worten: Zu ambitionierte Zielsetzung. Streich irgendeine der
Wünsche und Du kannst evtl. glücklich werden. _Ich_ würde mit iPhoto
anfangen aber meine Ansprüche sind da wohl berufs-massig-versaut viel zu
hoch.

Zur Zeit behelfe ich mir mit Symlinks von Originals und Modified auf
die Freigabe/Mountpoint (/Volumes/SHARE), aber die Lösung find ich
nicht so prickelnd.



Falls die Symlinks _innerhalb_ der Netatalk-Share (sowohl Ziel als auch
Quelle) sein sollten, hast Du noch eine Todsünde mehr begangen ;-)

Gruss,

Thomas

Ähnliche fragen