Broken "Invalid font resource" marking symlinks as corrupt [Closed]

MainType - Font Manager MainType - Bug Reports
1

I seem to remember this from some time back. For some reason, Maintype is claiming that 100’s of my fonts are corrupt and have a bad magic number. The bad magic number is (213C7379) which corresponds to the first 4 letters of
a Windows .

I’ve seen apps not understand windows desktop links, but everything that opens files follows windows symlink
codes that appeared about 10-15 years ago on Windows 7, maybe were on Vista before that.

Unfortunately, the fact that Maintype detect these as “corrupt font files” that it wants to delete is a bit scary since I
know other applications use them “just fine”.

I have my fonts installed in more than one location due to different application (and OS) needs.

is there a fix or patch for this problem? Both the main font and the symlink are in valid locations (needed in
each location). I’ve never seen any application have to do anything special since all of the OS-calls automatically follow
the links..

Ideas?
Thanks!
Astara :cry:

2

Can you please further explain the problem. Have you placed such symbol links inside Windows Fonts folder, or on another part of your file system. Are the fonts installed, and if so, how did you install them?

Are you running the latest version of MainType?

3

The links are under “/usr/share/fonts/”. There are some subdirs under it for Truetype and other types that are used by various Posix-ish and Cygwin apps, though primarily the cygwin-X server or other X-server apps. I’m not sure if other “remoting” apps make use of them or not.

I believe I’m running Maintype 8 which is the highest version I think I’m licensed for. If there’s an update beyond that that is covered by my license, I would be happy to try it, but window’s symlinks I think came out with vista or about or close to
20 years ago – so it’s not a new feature.

The fonts were not installed through maintype, if that’s what you were asking, but were pre-existing to the installation of maintype.

Did that answer your question(s)?
Thanks for your help!

4

So you have a network drive which contains the symlinks?

You can still buy an upgrade, but at some point that is not possible anymore, then you need to buy a full new license.

I need a way to reproduce this here, but so far it is still confusing to me. Maybe some screenshots help.

5

I could, but the links I am talking about are on my local ‘C-drive’.

I have a cygwin installation (from https://cygwin.com) installed in the root of my ‘C-drive’. Cygwin defaults to installing in C:/cygwin, so it doesn’t need to be in ‘/’ (the root), but I find it more convenient. Cygwin allows you to run POSIX (linux) programs on your PC. Fonts for unix/linux/cygwin are usually installed by packages (or singly) in /usr/share/fonts/ under the directory one installs cygwin. Using the default install directory, “C:/cygwin”, the fonts would be under “[C:/cygwin]/usr/share/fonts”. For me, I have my installation
dir = ‘/’ (or C:\ ). You don’t need cygwin to duplicate this, but I am not very familiar with Windows scripting. If you have a cygwin
installation or want to install it, I can show how to reproduce using that, but I’ll try to give a reproducer case without it.

[quote=“, post:3, topic:7273”]
I believe I’m running Maintype 8 which is the highest version I think I’m licensed for. If there’s an update beyond that that is covered by my license, I would be happy to try it, but window’s symlinks I think came out with vista or about or close to
20 years ago – so it’s not a new feature.
[/quote]

You can still buy an upgrade, but at some point that is not possible anymore, then you need to buy a full new license.

Yes, I know I’ have ‘8’ and current is ‘10’. When ‘9’ came out I didn’t think I needed the new features, and there was this problem with Maintype not working with Windows symlinks – showing well over 100 “corrupt fonts” which aren’t corrupt.

The easiest way might be to create a symlink to an existing font in the Windows font directory. That should reproduce it, though to be honest, I have no idea why Maintype isn’t seeing the file but it seeing the entry for the symlink code. I’ve not seen such except for
Windows Desktop links. I’m wondering if you are using some libraries that don’t use the win32 interface? I’ll have to get back to
this note to add more info – reproducer and screen shot(s)…

Wanted to get back though before I forgot about it! :wink:
Just a quicky: you need to use the “mklink” command in the cmd.exe shell, like: (bring up cmd.exe, will use ‘Lucida Console.ttf’ as an example, but will put it in C:\tmp (or temp):

> cd C:\tmp
C:\tmp> mkdir tst
C:\tmp> mklink tst\myfont.ttf "C:\Windows\fonts\Lucida Console.ttf"
symbolic link created for tst\myfont.ttf <<===>> C:\Windows\fonts\Lucida Console.ttf

C:\tmp>dir tst\myfont.ttf "C:\Windows\fonts\Lucida Console.ttf"
 Volume in drive C is System Disk
 Volume Serial Number is E889-68E4

 Directory of C:\tmp\tst

2021/05/14  18:56    <SYMLINK>      myfont.ttf [\Windows\fonts\Lucida Console.ttf]
               1 File(s)              0 bytes

 Directory of C:\Windows\fonts

2009/12/12  19:54           115,068 Lucida Console.ttf

If you try to index C:\tmp\tst in maintype, it should find ‘myfont.ttf’ and in maintype8, it claims it is corrupt (on Win7SP1-64bit).

If you look at ‘myfont.ttf’ in Internet Explorer, you will see myfont show as a “.ttf” file. I.e. right-click on it and I see ‘Preview’ as 1st option, which previews the font.

Does that help?

6

Yes, it did help. I have looked into the issue and with your explanation I now do understand the problem.

The next upcoming release of MainType will just ignore these symbolic links, as it would take a lot of time to properly implement support for it.

7

Really? Why would it take alot of time to implement support?

How do you handle duplicate entries, “otherwise”?

I mean if files are on the same disk/partition, they can be hardlinked as well. I’m not sure but I don’t think they can be differentiated – they’d show up as 2 names to the same inode (might have a different
name in NTFS, but same concept exists).

Since they are dups or pointers to another font file, it wouldn’t be horrible to ignore them, as one
might assume the font file could be included under its original name, but hardlinked files – might want to detect them – I sometimes see them used for different names for the same font…like a short-name and a longname.

Well, too bad I can’t tell it to ignore checking for ‘invalid font files’. Glad I could help you find it.

8

There are many things that go wrong, for example MainType indexes and then shows fonts in a sync folder. If one is a symlink, and MainType would process the actual target file, it would then not be part of the sync folder, as it is actually located in another folder. Whatever solution we choose in this case, it is always causing trouble, and then there are probably way more issues we haven’t thought of yet.

9

FWIW, the win symlinks are very similar to linux symlinks.

on Linux, many tools have an option to ignore symlinks (treat them as a non-original and don’t
follow them for terms of recursive path exploration), OR follow the symlink and treat them
as equivalent to the real file.

Of note – symlinks can also point to directories, so if I had i
C:/windows/fonts/
containing my Win fonts, then a symlink:
C:/usr/share/fonts/windows <==> C:/windows/fonts.

Then maintype say reads fonts in both dirs:

C:/windows/fonts/
C:/usr/share/fonts/windows/

You’ll have duplicate font listing and it will look like a normal font
file in each of those “dirs” – though they would have the same “inode”
or “fileid”.

Similarly a hardlink will allow two different names to point to one real file.
Both will look like real fonts, but again, the ‘inode’ or fileid would be the same.

Windows also has a few other soft-mount type features that function similarly
to the softlinks, junctions and mountd(or mountvol), mountd/vols allow mounting
a copy of another directory in a different location.

You can filter out the soft link stuff, but the hardlinks, or duping a directory into
another location can really only be detected by keeping track of the file-id/node
numbers and seeing if any are dups.

Also, if you have an option to allow following softlinks as though they were
real links, you have to keep track of the inodes /file ids as you explorer
directories, because you can have cyclical loops. Tools like ‘find’ in linux/posix
and cygwin as well as many of the linux/cygwin command line tools have
code to detect file-loops because there are so many ways to create them
now…

Anyway, Just giving information about various problems as a heads up.
For my own work , I’ll prolly have to limit maintypes directory scanning
to try to avoid symlinks as a workaround.

cheers and sorry to be bearer of unexpected-input… :wink: