Roland,
yes, I think that’s exactly why he’s seeing the zero size font file. By
checking the size of the companion .Appldouble/filename.ext he should get
something that approximates the file size reported by the OS X client logging
into the share.
Netatalk is able to use extended attributes
but this does not explain why the files on the destination are 0kb sized - with that background information you delivered, i assume they may already be 0kb on the source side - but Ram may have overseen that because he did not look from the shell`s point of view but from the OSX point of view via
Hi Ram,
In OS X, some font types (not all) put the font payload in the resource fork.
Netatalk provides AFP filesharing, imitating the resource forks by creating
secondary files in “.Appledouble” folders within each folder. Netatalk tracks
the resource forks, and other metadata, by keeping a
