Community
Participate
Working Groups
Build Identifier: 3.5.1R35 - 3.6.0.v20100602 When you try to copy & paste or drag & drop files such as Font Suitcase files into a folder in the Eclipse UI, a file is created but not copied. The destination file shows the right name, but is size 0. Reproducible: Always Steps to Reproduce: 1. open your font folder in Finder (Macintosh HD/Library/Fonts) 2. copy and paste or drag and drop a Font Suitcase file (i.e. a font without an extension) into a folder in the Eclipse UI 3. Examine the destination folder in Terminal or Finder to find out that the copied file has the size 0
When I look at the Fonts folder in Terminal I get zero size for Font Suitcase files and some size for the rest: -rw-rw-r--@ 1 root admin 0 Mar 7 2007 Academy Engraved LET Fonts -rw-rw-r-- 1 root admin 82080 May 31 2008 AlBayan.ttf -rw-rw-r-- 1 root admin 81852 May 31 2008 AlBayanBold.ttf -rw-rw-r-- 1 root admin 1254080 May 31 2008 AmericanTypewriter.dfont Is it a special kind of file/folder?
Unfortunately, I'm not enough a Mac pro to be able to provide details, but yes, the Font Suitcase files seem to get a special treatment in Finder. The '@' sign in the directory listing probably hints at some sort of symbolic link that needs to be resolved. 'file FontName' results in 'FontName: empty', though.
> The '@' sign in the directory listing probably hints at some sort of symbolic > link that needs to be resolved. 'file FontName' results in 'FontName: empty', > though. I *guess* the @ symbol indicates that there is attribute added to the file. All Font Suitcase files seem to have the com.apple.ResourceFork attribute (try running 'xattr *' in the Font's directory) Apart from that not sure of how to copy the resource fork attribute. Adding Scott & Lakshmi for comments
Wow, a font suitcase! Talk about old school. :-) In an 'ls -l' listing an @ sign after the file name signifies a symbolic link. An @ sign in the permissions information means 'extended attributes', which in this case likely means a resource fork. Java file operations are all Unix-based, so they only work on the equivalent of the data fork. All Java apps have this problem, not just Eclipse. But, we could support resource forks if needed.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
