Fonts as Zero Bytes on SMB Share

[Joe]

Re: spoiler tags: Not in this version. It is in the next major upgrade which has been in beta testing for 6,413 years now.

[AaronH]

Ooooh maybe we'll get them when we are doing prepress work from the space station on our way to the Mars colony.

[Joe]

Maybe....but don't bet actual money on it.

[AaronH]

Only cryptocurrency.

[Joe]

Just to update this thread with current information I am seeing....

My Netgear ReadyNAS Pro 6 went down the path to death. Can't find another one by Netgear cheaper than $3,700 so I bought a Synology DS1621xs+ (6 bay)
and 6 Seagate Enterprise drives.

The old Netgear NAS was using SMB 1 and never had any issues with copying fonts via SMB from Mac to NAS and back. In fact that is where our old repository of old Postacript type 1 fonts reside.

The new NAS is using SMB 3. When I copy fonts from the old NAS to the new NAS the postscript type one fonts show as zero kb. Much to my surprise they still work ok. And if I copy back to the Mac via the Mac finder they show the correct size. If I download the fonts from the Synology NAS GUI via web browser they come back to the Mac as zero kb and are completely hosed.

Looking at the old NAS folders with viewing invisible files I see both the font data fork file and the Mac resource fork file. Same name as the data fork file with a period at the beginning of the file name which makes it invisible. So here is a little history on how the Mac data fork and resource fork operates...

Behind the scenes

When you come from the Windows world, you'll know that a filetype is determined by the file extension. A Word document is only recognised as such when it has the extension .doc (or .docx). When you change this to something else, or completely remove the extension, Windows has no idea what kind of file it is and thus with which program to open it. One could say this is a stupid way to handle it – why not have the file type stored as meta information inside the file itself, so there's no risk that users kinda destroy their files by accidentally changing their extension.

On Macs, this is handled differently. There is meta information, this must be stored somewhere in the Mac file system HFS(+), NOT in the file itself. This leads to problems, because this is one of many "we're Apple, we're doing it completely different than the rest of the world, so we're incompatible to the rest of the world" things.

Analysing the problem

So, on a Mac, "regular" data is stored in the file itself, called data fork, but metadata (like embedded images, icons, image preview thumbnails, ...) is stored in the so-called resource fork. This is done, as mentioned, in some place related to the file system.

Now other file systems do not support these resource forks, so that they would get lost if you copy a file from a mac to a different FS. A Mac solves this as it splits the resource fork into a second file, which has the name of the actual file, prefixed by dot underscore (._). So if your file is called tree.jpg and you copy it to a SMB share for example, a second file will be created there called ._tree.jpg.

Normal users won't see these because files prefixed with a dot are hidden by default. Anyway, if you have "show hidden files" enabled or do "ls -la" on a UNIX-based system, you can see them.

Now when you copy this jpg back to a Mac, it seems to be clever enough to look for a corresponding resource fork file, copy that one over as well and then automagically merge both (or rather store the metadata from the ._-file in the HFS file system again). So usually, copying stuff from or to a SMB share or some other volume with non-Mac file system should work flawlessly. Unless you delete the ._-files on that volume – this breaks some files which have important data in the resource fork.

Mac fonts apparently store all their data in the resource fork; their data fork is empty. Example:

On your desktop, you have font called MyFontBold – the finder says it's 40kb in size and it's a PostScript Type 1 Outline Font. Now open a terminal and do a ls -la on the desktop, you'll see this:

Code Select Expand

-rwxrwxrwx 1 youruser youruser       0   Mar 14 2009   MyFontBold

indicating that the actual file has 0kb in size. Now copy this file to a different file system, for example on a UNIX server. The finder again lists the font with the correct size and icon, but in the terminal you'll see this:

Code Select Expand

-rwxrwxrwx 1 youruser youruser   40172   Feb  3 2010   ._MyFontBold
-rwxrwxrwx 1 youruser youruser       0   Mar 14 2009   MyFontBold

Now you can see that the actual data of the font is stored completely in the resource fork because the newly created file (look at the timestamp) apparently has some content due to its file size, while the original font file is still empty (0kb). And now it's clearly understandable that, when you remove the resource fork file, the Mac can't do anything with the data fork file – the font is irreparably broken. However, this is only possible on non-Mac file systems, because the relevant data from the resource fork is stored in the file system itself on Mac file systems and thus cannot be deleted by accident.

So on normal files the actual data is stored in the data fork file while postscript type one fonts store all of their data in the resource fork file instead of the data fork file. Thanks font foundries of old. That is why if you have image or document files as long as you have the data fork file you can still use the files. But not with postscript type one files. If you lose the resource fork file the font is gone.

If you remember in the old days on a Mac you rarely used a file extension on files. The resource fork file is where the data resided to tell the Mac what application is associated with the file. For example back then you could have an InDesign file and Quark file with both names the same with no extension but the Mac would open the correct app for the files with all data there because that info was in the resource fork file.. But once the resource fork is gone the Mac would longer know what app was supposed to open it with. And it would usually change the icon to the. black square and list it as a UNIX file.

So back to my old NAS using SMB 1. SMB 1 used something called Apple Double so that those resource for files woould be copied along with the data fork files and then they woould be copied back to the Mac as well. It also does that if you use AFP instead of SMB 1.

However both AFP and SMB were deprecated around 2014-2015 and SMB 2 came along and now SMB 2/SMB3. I think they do not use Apple Double as I don't see the invisible apple double and resource fork data files. I'm not sure what kind of black magic they use now as copying the files via SMB 3 on my new NAS does not copy the resource fork files and the resulting data fork files show as zero KB but they still work fine. And then as I said earlier when I copy back the data fork files they are the correct size but no longer have the resource fork files anymore. And as mentioned previously type one fonts store their data in the resource fork files so my only conclusion is that SMB 3 knows about the data fork and resource fork files and must somehow keep the data in a single file. Still no idea while the file manger on the NAS and Mac Finder shows them as zero KB but I can still use them and copy them back.

Conclusion: The new NAS works with the old fonts with SMB 3. Somehow.

[Tracy]

going to have to print and read this tomorrow!
Way to go Joe! If it was me I prolly would of thought all was lost

[Joe]

My second conclusion is that we need to stop using 40 year old postscript type 1 fonts. 

[David]

I can quit anytime...

[Joe]

LIAR!!!!!...

[Tracy]

sheesh 40 year old fonts, that's crazy
wasn't it just yesterday?

[David]

sheesh 40 year old fonts, that's crazy
wasn't it just yesterday?

for me, it was the day before yesterday...

[scottrsimons]

If I remember correctly, and that's saying something, AppleDouble was something they came up with when Apple started using SMB (1 back in the day). It was a way to keep on using Apple's files in a non AFP system. More importantly, sharing files on the network with DOS/Winbloze Windows. And now that Apple has finally decided to put to death AFP, so does AppleDouble go that way too.

Guess when we are using files that we designed to be used on that old system that is no longer "supported", we wonder why there is a problem.

But as all good Prepress people we are, we keep fighting the good fight.

[Joe]

My first recollection was when Prinergy was installed and the guy said we had to use AppleDouble because Microsoft Windows 2003 Server didn't include AFP anymore. So we had to use SMB for the Macs to access the job drive and they had to enable AppleDouble in the Prinergy administrator. When we got the NAS we just used SMB on that but there was no setting for AppleDouble but it used it because it creates invisible AppleDouble files on it.

On the new Synology NAS we bought it does SMB 3 and there are no invisible Mac resource for files to AppleDouble files and all files seem OK though the old postscript type 1 fonts show as zero KB and still work and when copied back to the Mac they are the right size.

My support case with Synology has been escalated to their developers in Taiwan so see why they display as zero kb. And also if you download the files using their own file manger app it makes the downloaded files zero kb and they are hosed at that point.

[scottrsimons]

I have noticed similar, but have not fully tested. When using Mac and Synology, it seems to work fine with Mac PS fonts. Once you copy any of the fonts with a PC, they are hosed. Best thing to do, if you really want to keep those fonts around is to create a library of them, and then compress them before you save them to a NAS or anywhere other than the Mac that they are currently working on. It's the same thing I used to do back in the day with most files. No matter how I was moving/copying them, whether it be via ethernet/Zip/Jaz/floppy/FTP/Ext HD.

[Joe]

Is your Synology NAS using SMB 3 / SMB 2? And if so do the postscript type 1 fonts show as zero kb on the NAS? And still work?

I have several copies of the fonts scattered around.