Hey guys,
I'm getting an interesting issue. For some reason, some of my fonts on the SMB share in InDesign's Document Fonts folder are showing up as Zero Bytes after copying over to it.
On the Desktop, they show as having actual file sizes. Unfortunately the way we have to work here at the shop is on the network, because if I have to do any changes to it, I have to copy back from the server which still produces Zero Byte font files on my desktop.
Any idea why my fonts would show up as Zero Bytes and then of course not work?
Thanks,
Aaron
AFP versus SMB
These were probably copied over as a AFP server mount at one point and now you are using an SMB mount and it doesn't copy over the Mac resource fork.
A lot of times (YMMV), if you are using Indesign and you also have a "Document Fonts" folder residing next to the ID file, it will recognize them, even tho they are zero K.
That was my problem, InDesign wasn't recognizing the fonts even with the Document Fonts folder in the same location as the INDD file.
That makes sense though about the SMB vs AFP thing though.
I wish we could get our server situation fixed but it's looking like it's not ever going to be fixed.
Quote from: david on November 25, 2019, 01:47:06 PM
AFP versus SMB
These were probably copied over as a AFP server mount at one point and now you are using an SMB mount and it doesn't copy over the Mac resource fork.
A lot of times (YMMV), if you are using Indesign and you also have a "Document Fonts" folder residing next to the ID file, it will recognize them, even tho they are zero K.
If you are archiving Mac fonts to a Windows server using SMB, .zip the fonts BEFORE copying to the server to maintain them.
Copy the known good fonts to your Mac via AFP. Now copy them back to the server via SMB. From that point on you should be able to copy those fonts back to a Mac via SMB without them going to 0 kb.
I tried that. The good fonts are on my desktop, from an AFP location, then unzipped since we still can't unzip on the network, then copied to the SMB share. The fonts all have sizes on the desktop but not all of them do on the SMB share. If copied to the desktop from the SMB share, it keeps the ones that have zero bytes as zero.
The fonts that have zero bytes aren't recognized by Adobe.
Fonts that are zero kb are dead and aren't ever coming back.
Quote from: AaronH on November 25, 2019, 02:40:45 PM
I tried that. The good fonts are on my desktop, from an AFP location, then unzipped since we still can't unzip on the network, then copied to the SMB share. The fonts all have sizes on the desktop but not all of them do on the SMB share. If copied to the desktop from the SMB share, it keeps the ones that have zero bytes as zero.
The fonts that have zero bytes aren't recognized by Adobe.
So after you have them on the Mac and unzipped and none of them are zero kb and then you copy them via SMB to an SMB mounted share some of them still go to zero kb?
Quote from: Joe on November 25, 2019, 02:44:16 PM
So after you have them on the Mac and unzipped and none of them are zero kb and then you copy them via SMB to an SMB mounted share some of them still go to zero kb?
Correct.
That doesn't make a lot of sense. Just to be sure....when you copy them from the Mac to the NAS that share was mounted via smb?
If you do a get info on the NAS share it shows it is mounted via smb like this?
Yep. I've disabled all other forms of connection on the NAS software.
How old is this NAS again? I know we have discussed this on the other thread but I am suspecting that the NAS may be using SMB 1 while your Mac may be using SMB 2/3 and there are known issues if you mix the two versions of SMB. Other than that I am stumped on your network issues.
its 4-5 years old. It does say it is using SMB 3 according to the NAS OS Update Notes.
Weird. Open a Terminal window on your Mac with your shares mounted and type this in:
smbutil statshares -a
That will tell you the version of SMB all shares are using. I just tried it on my Mac and my NetGear NAS shares are all using SMB 1. My Windows 7 shares are using SMB 2.1 and Windows 2012 R2 Server shares are all using SMB 3.02. And they all seem to be working OK for me.
You may want to take a look at this article too: Fix SMB connection problems for Mac (https://www.nathanson.org/davesays/2019/fix-smb-connection-problems-for-mac/)
Mine are all using SMB 3.02.
QuoteLast login: Thu Nov 14 14:33:43 on ttys000
You have mail.
Aarons-iMac:~ ncg$ smbutil statshares -a
==================================================================================================
SHARE ATTRIBUTE TYPE VALUE
==================================================================================================
Office
SERVER_NAME NCGFILESERVER2._smb._tcp.local
USER_ID 501
SMB_NEGOTIATE SMBV_NEG_SMB1_ENABLED
SMB_NEGOTIATE SMBV_NEG_SMB2_ENABLED
SMB_NEGOTIATE SMBV_NEG_SMB3_ENABLED
SMB_VERSION SMB_3.02
SMB_SHARE_TYPE DISK
SIGNING_SUPPORTED TRUE
EXTENDED_SECURITY_SUPPORTED TRUE
UNIX_SUPPORT TRUE
LARGE_FILE_SUPPORTED TRUE
OS_X_SERVER TRUE
DFS_SUPPORTED TRUE
FILE_LEASING_SUPPORTED TRUE
MULTI_CREDIT_SUPPORTED TRUE
ENCRYPTION_SUPPORTED TRUE
--------------------------------------------------------------------------------------------------
XMF_Files
SERVER_NAME NCGFILESERVER2._smb._tcp.local
USER_ID 501
SMB_NEGOTIATE SMBV_NEG_SMB1_ENABLED
SMB_NEGOTIATE SMBV_NEG_SMB2_ENABLED
SMB_NEGOTIATE SMBV_NEG_SMB3_ENABLED
SMB_VERSION SMB_3.02
SMB_SHARE_TYPE DISK
SIGNING_SUPPORTED TRUE
EXTENDED_SECURITY_SUPPORTED TRUE
UNIX_SUPPORT TRUE
LARGE_FILE_SUPPORTED TRUE
OS_X_SERVER TRUE
DFS_SUPPORTED TRUE
FILE_LEASING_SUPPORTED TRUE
MULTI_CREDIT_SUPPORTED TRUE
ENCRYPTION_SUPPORTED TRUE
--------------------------------------------------------------------------------------------------
Local Backup
SERVER_NAME imac2._smb._tcp.local
USER_ID 501
SMB_NEGOTIATE SMBV_NEG_SMB1_ENABLED
SMB_NEGOTIATE SMBV_NEG_SMB2_ENABLED
SMB_NEGOTIATE SMBV_NEG_SMB3_ENABLED
SMB_VERSION SMB_3.02
SMB_SHARE_TYPE DISK
SIGNING_SUPPORTED TRUE
SIGNING_REQUIRED TRUE
EXTENDED_SECURITY_SUPPORTED TRUE
UNIX_SUPPORT TRUE
LARGE_FILE_SUPPORTED TRUE
OS_X_SERVER TRUE
FILE_IDS_SUPPORTED TRUE
FILE_LEASING_SUPPORTED TRUE
MULTI_CREDIT_SUPPORTED TRUE
DIR_LEASING_SUPPORTED TRUE
ENCRYPTION_SUPPORTED TRUE
SIGNING_ON TRUE
--------------------------------------------------------------------------------------------------
Aarons-iMac:~ ncg$
Are spoiler tags available?
I'll take a look at that link. Thanks 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. :sarcasm:
Ooooh maybe we'll get them when we are doing prepress work from the space station on our way to the Mars colony.
Maybe....but don't bet actual money on it.
Only cryptocurrency.
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+ (https://www.synology.com/en-us/products/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...
QuoteBehind 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:
-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:
-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.
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
My second conclusion is that we need to stop using 40 year old postscript type 1 fonts. :o
I can quit anytime...
:lmao:
LIAR!!!!!...
sheesh 40 year old fonts, that's crazy
wasn't it just yesterday?
Quote from: Tracy on April 20, 2021, 09:33:18 AM
sheesh 40 year old fonts, that's crazy
wasn't it just yesterday?
for me, it was the day before yesterday...
:lmao:
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.
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.
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.
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. :rotf:
I don't exactly remember what SMB version we are using, as I fought through getting it setup correctly. And yes our PS type 1 fonts do show zero kb on the NAS, but still work and show the correct size when copied back to the Mac. I guess that is why I haven't noticed yet, as no one has yelled at me for the issue.
Don't worry though, in a couple of years we won't have PS type 1 fonts that will work anyways. And there will no longer be any print, as everything will be digital. Or at least that is how all the designs coming in seem to be. :sarcasm:
Good to know they are working the same for you that they are me.
Synology is wanting me to install Wireshark on my Mac and do some packet captures to send to them and I'm like wut???? Are you crazy? This isn't rocket science. Cop;y some damn fonts to the NAS and look at them. You don't need packet captures for that. Just eyeballs.
Synology is too new of a company to know of the blackmagic we have had to deal with, when it comes to older Mac files. Especially PS type 1 fonts. Anything that was designed for System 9 and before, was great for then, but working on current systems not so much.
Bought 6 new Seagate Enterprise drives for this thing. One of them is reporting errors today. :death:
We used to use Seagate Archive drives in our, and had errors quite often even though the drives were OK. The switched to Seagate IronWolf drives and haven't had any problems. So once one old drive acts up, we immediately replace with IronWolf, and they've been solid in our Synologys.
I looked at them but I only wanted 2 TB drives and the Ironwolf 2 TB drives are only 5900 RPM. I didn't want to get below 7200 RPM and the first Ironwolf drive that is 7200 RPM is the 6 TB one and it runs $231 a piece. I've always used the Seagate Enterprise drives in our NAS units and have had pretty good luck with them. Luckily I'm still under 30 days since purchased on Amazon so I should be able to get a replacement.
Don't forget the IronWolf drives also come with 5 year warranty. I've had to use it once or twice. Very nice indeed (no I'm not looking for a job either :cane: ).
Wave hello to the Synology support team who referred me to my own lengthy post previously in this thread.
:facepalm:
:rotf:
:shoots_self:
:drunk3:
Quote from: Joe on April 22, 2021, 12:43:08 PM
Wave hello to the Synology support team who referred me to my own lengthy post previously in this thread.
:facepalm:
you are apparently a very popular guy...
:banana: :banana:
If you have several days, and nothing better to do, copy all the fonts to a Mac. Then copy them back to the NAS using the AFP. Should have the display with correct size instead of 0.
Does anyone know how to author a script for Windows that can remove "-1" from a filename in tens of thousands of folders and subfolders?
Quote from: DigiCorn on April 23, 2021, 02:17:20 AM
If you have several days, and nothing better to do, copy all the fonts to a Mac. Then copy them back to the NAS using the AFP. Should have the display with correct size instead of 0.
Does anyone know how to author a script for Windows that can remove "-1" from a filename in tens of thousands of folders and subfolders?
Yes I tested AFP and it works but we are not going to use AFP. It has been deprecated since 2014 and they have finally removed it from Big Sur. Use it now and pay a price later.
Even though the fonts show zero KB they are not hosed. I can install them from the NAS drive and they work. I can copy them back to the Mac and they show the correct size. My concern right now is what happens when I do a backup form the NAS to an external hard drive? Are they still showing zero and useable? Or are they really zero and at that point and hosed? The concern comes from the fact that if you download them from the NAS to the Mac with the built in File Station file manager the files actually become zero kb and are hosed. Haven't tried a backup yet to see what happens. It would be nice if they could figure out a way for it to just work. It would also be nice if we could just throw every postscript type 1 font in the trash, empty the trash, and move on.
Digi, why does your files have -1?
curious because my fix probably won't help
select all right click rename? put the -1 and then nothing in the other field
He said for Windows though. But I'm sure there are some freeware renaming programs on Windows (Bulk Rename Utility (https://www.bulkrenameutility.co.uk)) that would do it. You can do it from the Windows COMMAND line or using POWERSHELL too.
:laugh:
My excuse? chemo brain
I also recommend .zip ping the fonts in a 2nd backup to double down, just in case.
As anyone with iTunes knows, it can be a bitch sometimes. 12 years ago I committed ALL my CDs to Apple lossless format and purged my collection in favor of digital. For some reason, iTunes duped my collection during a transfer from a failing NAS to a newer NAS, and now I have a second copy of each file with a -1 after it. There's 19,000+ files, in thousands of folders and subfolders, so manually deleting them is really NOT an option.
Quote from: DigiCorn on April 26, 2021, 12:09:37 AM
As anyone with iTunes knows, it can be a bitch sometimes. 12 years ago I committed ALL my CDs to Apple lossless format and purged my collection in favor of digital. For some reason, iTunes duped my collection during a transfer from a failing NAS to a newer NAS, and now I have a second copy of each file with a -1 after it. There's 19,000+ files, in thousands of folders and subfolders, so manually deleting them is really NOT an option.
So they are on a Mac disk and you want to delete them and not rename them? From terminal navigate to the folder where they are located and enter this: rm *'-1'*
That will delete all files that have -1 in the name.
No. They are on a NAS, which I believe is Linux.
Quote from: DigiCorn on April 26, 2021, 10:19:44 AM
No. They are on a NAS, which I believe is Linux.
You can do it pretty much the same way on Linux from the command line. Just need to make sure ssh is enabled on the NAS and then SSH into it from Windows or a Mac.