4

I have two MacBookAirs, an older one where I installed MacTex-2018 and a newer one where I installed Mac Tex 2021. MacTex works superbly in both cases.

My older laptop died and I got a new MacAir and I have installed MacTex2022. The result is complete chaos. I have not experienced any of these problems with any of the previous incarnations of MacTex and I have been using this soft for more than 15 years.

There are too many issues to list them all, but here is a sample.

The 2022 version has problems processing files using the gsm-l package (created by the American Math Soc for authors). It cannot find this package apparently.I have no clue where to place this package. I did not have to do anything special when using version < 2022. If I change the option gsm-l to a world scientific .cls option Things work fine.

I use the packages pb-diagram, pb-lams, lamsarrow to generate diagrams. On some of my files they work. On most they do not. I have the lams fonts, placed them in the Library directory as usual but it does not help because, sometimes MacTex cannot find them. On other occasions I do not have thises issues.

The packages graphicx and epstopf also work erratically. That is, they work in some files, but on some other files they cannot seem to locate the .eps files. I have included in my texts jpg and png files. Same type of issue here. Works on some files fail on other.

I have not experienced any of the above issues using earlier versions of Mac Tex. I work in the cloud (Dropbox) so I have not changed the structure of the directories containing the tex files I am working on.

Admittedly, my computer skills are limited, but I have installed MacTex on about a dozen of Macs over the years and everything worked like I charm. I have followed closely the installation instructions and I now have in my laptop a "beast" whose behavior does not display any obvious pattern.

I currently have Monterrey 12.3.1, the same operating system on which MacTex 2021 on my other laptop works well.

I am out of ideas and I would appreciate any suggestions you might have. Thanks!

Update The mystery deepens. In my frustration I have installed MikTex for Mac I did the following experiment.

I ran a Tex file using TexShop/MacTex and I encountered various problems. The process ended with a Fatal Error message. Then I processed the same TeX file using miktex-texwork. Things worked well. I tried TexShop again on the file. It worked like a charm. No more problems.

Did the same think with other TeX files and I observed the same thing. TexShop works well only after I first process the Tex file using miktex.

Including log files here seems pointless. There are too many types of errors that vary from file to file to discern a pattern. I have my own TeX template so they all have the same preamble.

Final update It is about Dropbox. Starting with Monterrey upgrade Dropbox is not working properly. This affects the behavior of MacTex2022 as well if you try to work in the cloud. The earlier versions of MacTex do not seem to be affected by this.

Liviu Nicolaescu
  • 151
  • 5
    start with one of the issues and describe it correctly: make a small example and show it together with the log-file so that we can see the exact and full error message. – Ulrike Fischer Apr 29 '22 at 15:42
  • 1
    Where did you put the package before? That hasn't changed between previous versions and the 2022 version. If you put the file(s) in texmf-local you need to run sudo -H mktexlsr and give your admin password when requested. When you say you placed them in the Library folder what do you mean? – Herb Schulz Apr 29 '22 at 16:50
  • I am including a log file. It is a book 500 pages long. The output pdf now is only 4 pages long – Liviu Nicolaescu Apr 29 '22 at 17:13
  • I have a file (book) in two style versions. One that uses a World Scientific style package and one that uses the gsm-l package. The World Scientific version works like a charm. and produces a 500 page output.The gsl-m version stops at the first include graphics command. The epstopdf is the problem. The pdf output is 4 pages. I cannot include the log file because it is too long. – Liviu Nicolaescu Apr 29 '22 at 17:27
  • 1
    try to remove epstopdf from your file. The conversion call is now in-built. Remove also pdfsync.sty, that is obsolete since many year. – Ulrike Fischer Apr 29 '22 at 18:35
  • @UlrikeFischer I will try this. However I have epstopdf in both versions I mentioned above. Everything is fine when using Wolrd Scientific class but everything goes wrong when I use ams style files. – Liviu Nicolaescu Apr 29 '22 at 18:42
  • 1
    Well I wrote you should provide a small example. Then someone could test. – Ulrike Fischer Apr 29 '22 at 18:44
  • I removed the epstopdf and pdfsync Stll not working. Everything works fine with MacTex 2021. – Liviu Nicolaescu Apr 29 '22 at 18:46
  • 1
    well the first error is with the graphic. So it should be trivial to create a small failing example. Then would we no longer would have to guess what you do. – Ulrike Fischer Apr 29 '22 at 19:28
  • Here is what troubles me. Everything works wellwhen I use a World Scientfic template: graphics, diagrams, everything. If I use the same text with an amsbook template then all sorts of problems appear. – Liviu Nicolaescu Apr 30 '22 at 09:07
  • Sigh... having both MikTeX and TeX Live (installed by MacTeX can certainly lead to problems. We really need you to help folks here figure out what is going on by providing an example that fails that we can work with. – Herb Schulz May 02 '22 at 14:13
  • 1
    This has nothing to do with MikTeX, which I wouldn't recommend for a Mac. I'm using TL 2022 with Monterey and Dropbox without incident. Dropbox now runs with Files on Demand all the time, and it's likely that existing .aux or .sty files in user folders will be present but appear as having no content, which can lead to errors on existing documents. This can also affect your local texmf if you have it symbolically linked to a Dropbox folder. For .aux files, you can just delete them and recompile. For local .sty and .cls files, just reopen the file first then recompile. – Alan Munn May 02 '22 at 15:17
  • 1
    ...con't For a local texmf folder symbolically linked to a Dropbox folder, it's best to set that folder to be "Always available offline", which will stop Files on Demand from leaving files in the cloud. To do this, navigate to the folder in the Finder and then right-click/control-click on the folder icon. There will be Dropbox items there, choose the "Make available offline" item. – Alan Munn May 02 '22 at 15:18
  • @AlanMunn Thanks! I will do this and let you know what happens. – Liviu Nicolaescu May 02 '22 at 17:30
  • @AlanMunn I've made my folders available offline and so far everything seems to be working without a hitch. Thanks you very much. – Liviu Nicolaescu May 02 '22 at 20:26
  • Great! I’ll turn my comments into an answer then. – Alan Munn May 02 '22 at 22:16
  • @AlanMunn Please do and I'll award it. – Liviu Nicolaescu May 03 '22 at 08:49

1 Answers1

6

Based on the comments, I've managed to reconstruct the basic problem here, which relates to changes in the MacOS as of Monterey (OS 12) and apps like Dropbox and OneDrive.

As of MacOS 12, there are changes in the way that cloud based files are stored. Dropbox and OneDrive (and presumably other cloud sync solutions) now default to "Files on Demand" mode, which means that files that are not actively being used will remain on the server, and only get downloaded when opened. Effectively this means that although the files appear in the Finder as a kind of stub, they have no actual content. This is a problem that Dropbox and OneDrive are aware of, but have not yet successfully fixed. It is hoped that they will and the solutions given below will no longer be necessary.

Problems with (older) local files

When you try to compile a file which requires one of the "cloud only" files, the file will not be flagged as missing, (since it does exist), but it will effectively load no content. [Thanks to Phelype Oleinik for discussion of of how packages are loaded].

This will lead to errors in the following circumstances (probably a non-exhaustive list):

  • existing .aux files that are supposed to be read during compilation
  • files that are inserted into your main document with \input or \include
  • local (to the source document folder) classes or packages

If any of these files are "cloud only" the code they contain will not exist, and any macros they define will then give rise to "Undefined control sequence errors". Such errors can be very misleading, since you would assume that the files are all there, especially on existing documents that used to compile without errors before.

Problems with a texmf folder on Dropbox

Further problems can arise if you have your local texmf folder linked to a Dropbox folder as described here:

If you do have this setup, then many of your locally installed packages and classes will have a "cloud only" status, and so will give rise to errors if you try to load them.

Solutions

Depending on the situation, you can solve the problems in either a specific or general way.

Individual folder solution

For .aux files, simply deleting them before recompiling an old document should be sufficient.

For local \input or \included files or local to the source document folder packages or classes, simply opening these files first in your editor will download them and they will be usable again.

General solution

For a texmf folder linked to Dropbox, the solutions above are impractical. In this case a better long term solution is to make sure that the linked Dropbox folder is set to be "Make files available offline". This will stop the "cloud only" status from applying to that folder. Since the status applies recursively to all containing files and folders, you just need to set that status for the top level folder. To do this, right-click (or control-click) on the Finder icon for the folder, and there will be a set of Dropbox menu items. Choose the "Make available offline" item.

Of course this solution will work for any individual folders, and since .tex files usually aren't large, it's probably fine to use it for an folder containing .tex files. But in practice, I don't think it's necessary for most situations, since the individual folder solutions are adequate.

There's also a global Dropbox setting to turn off Files on Demand, but this seems like a non-optimal solution, since Files on Demand is generally a useful space saver.

Alan Munn
  • 218,180