[OS X TeX] troubles with TeXShop and network disks

[wambacq]

Hi Dick,

thanks for your response. I understand that you are too busy right now and that you don't have the software that I use. But I want to add some more information below that could be interesting to other people who read this and who are using a similar setup:

- I run TeX locally, but the files that need to be typeset are on a network volume

- there is no need to move back a resulting pdf to my mac at the end of the script; the network volume should behave in the same way as a local volume. If this works as expected, nothing needs to moved around. You are right that files can be copied over the network to my machine, processed locally and at the end of the day everything can be copied back but this is a hassle and since then there are two versions of the files (locally and remotely) this is a recipe for diverging versions if I am not careful enough (yes, I know that this can be scripted, but still). And it is not needed if the network volume behaves as expected.

I am waiting for the support engineers of Mountain Duck to hopefully come up with a solution.

Thanks

Patrick

> On 1 Aug 2018, at 16:54, Richard Koch <koch at uoregon.edu> wrote:
> 
> Patrick,
> 
> I am very busy working on changes needed for Mojave, and won't have time to think about
> your problem. It is the sort of problem I usually cannot solve, since it depends on hardware
> and software I do not have.
> 
> Do you have TeX on your local machine, or do you access that as well over the server?
> 
> It seems to me that rather than worrying about all this networking, you could just typeset locally
> with the source in a local folder, and then at the end of each day copy that folder to the server.
> Of course if the server is working correctly this wouldn't be necessary, but if it isn't doing the
> correct thing, then spending time fixing it might not be worthwhile.
> 
> I should add that TeXShop works fine with Apple's iCloud, but that is because TeXShop
> is written in Cocoa, so these difficult network problems are solved by Apple engineers
> and not by me.
> 
> Here's how TeXShop works. Let's think in terms of a general typesetting "engine script"
> of the type that TeXShop can use.
> 
> The engine is a shell script, which can have several steps. Each of these steps is done in
> turn. At the very end, after the engine runs, TeXShop looks in the source folder to see if it
> contains a pdf file. If so, then it displays that pdf file. That's it. There is no deeper connection
> between source and pdf. So: put source in a folder; run a script that interacts with that folder;
> in the end, does the folder contain a pdf file; if so display it.
> 
> If you are telling me that the typesetting occurs over the server, and the resulting pdf file isn't
> moved back to the Mac, then that's a problem, but it's not my problem, since TeXShop knows
> nothing about that server.
> 
> Dick Koch
> 
> 
> 
>> On Aug 1, 2018, at 7:32 AM, wambacq <Patrick.Wambacq at esat.kuleuven.be> wrote:
>> 
>> Hi,
>> 
>> my department has a linux file server with latex source documents, that I access from my mac over the network. I used to do this with a combination of fuse, sshfs and Macfusion. But the latter has really become unstable lately so I looked at alternatives and than I ran into problems.
>> 
>> I found Mountain Duck (from the creators of CyberDuck) that seems to do the trick. I can easily mount volumes over ssh and access them as if they are local volumes, which is what I want. And this also works from home, without vpn. Other software can do similar things, but usually there is no integration with the Finder (you have to drag files around in the application's window), and this is what I like about Mountain Duck (and previously Macfusion).
>> 
>> But TeXShop does not render the result of consecutive typesetting steps correctly. It does not detect that the second step changes anything ino the output (i.e. the pdf window still does not show references, the toc etc). But if the output of the steps is viewed externally with another pdf viewer, it shows that the pdf contents are as expected. It's just that TexShop does not detect this because of missing temporary files or metadata (I think).
>> 
>> I suspect that this is caused by a feature that was recently added to Mountain Duck, quoting from their webpage: "Extended attributes and temporary files from applications are no longer saved on the remote volume but in a local temporary cache only.". See https://blog.cyberduck.io/2017/11/27/skip-writing-temporary-application-files-to-remote-volume/. I tried an earlier version of Mountain Duck, from just before this feature was added, and the problem goes away.
>> 
>> Can this indeed be the cause? And can something be done about it from the TexShop side? I sent an email to Mountain Duck support but have not yet received an answer. If I would find the location of Mountain Duck's local cache (but I still have to find it), is there a way to tell TexShop to look there?
>> 
>> Thanks
>> 
>> Patrick
>> ----------- Please Consult the Following Before Posting -----------
>> TeX FAQ: http://www.tex.ac.uk/faq
>> List Reminders and Etiquette: https://sites.esm.psu.edu/~gray/tex/
>> List Archives: http://dir.gmane.org/gmane.comp.tex.macosx
>>               https://email.esm.psu.edu/pipermail/macosx-tex/
>> TeX on Mac OS X Website: http://mactex-wiki.tug.org/
>> List Info: https://email.esm.psu.edu/mailman/listinfo/macosx-tex
> 
> ----------- Please Consult the Following Before Posting -----------
> TeX FAQ: http://www.tex.ac.uk/faq
> List Reminders and Etiquette: https://sites.esm.psu.edu/~gray/tex/
> List Archives: http://dir.gmane.org/gmane.comp.tex.macosx
>                https://email.esm.psu.edu/pipermail/macosx-tex/
> TeX on Mac OS X Website: http://mactex-wiki.tug.org/
> List Info: https://email.esm.psu.edu/mailman/listinfo/macosx-tex