Sumatra PDF does not reload document on compile

[brennon]

The first time I compile a LaTeX document, the PDF opens in Sumatra PDF, scrolled to the position of my furthest edit since my last compilation. After this, if I make changes to my LaTeX document and compile it again, the section of the PDF where my edit was performed is scrolled into view and highlighted momentarily in Sumatra PDF, but the new PDF isn't actually loaded. I have to manually reopen the document in Sumatra PDF in order to see my changes.

Sublime Text 3.1.1, Build 3176 Sumatra PDF 3.1.2 LaTeXTools 3.15.1 Windows 10 Enterprise (1709)

[YoichiMukai]

Did you find out how to fix it? I have the same issue.

[r-stein]

In the sumatra pdf advanced settings there should be a line ReloadModifiedDocuments = true, which tells Sumatra to automatically reloads documents. This doesn't seem to work if the pdf file is bigger than 10 MB.

[YoichiMukai]

My file is smaller than 10MB and ReloadModifiedDocuments is set as "true" but I am still having the issue.

[r-stein]

Sorry then I also don't know whats the problem.

[YoichiMukai]

Thank you, though.

[brentcody]

I have the same problem. Has anyone resolved this?

[mirh]

Options really aren't it, because I have the same exact ones with the exact same builds on two computers, and yet one works the other doesn't. So: either it could be some magic in the slightly different latex environment I have here, who knows.. or way more probably it's a W10 problem (because it sure is perfect on W7)

In fact something similar happens almost by design on non-ntfs filesystem, since the program is entirely dependent on some notifications the OS doesn't send https://github.com/sumatrapdfreader/sumatrapdf/issues/596

[mirh]

Jesus, the more I try, the less I think to know. Possible stuff

• Windows api shenanigans (it wouldn't be the first api they broke randomly)
  • indeed, half of the dll sumatra gets to load are different between w7 and w10
• Sumatra has some broken code, or it has some bitterness for some hardware
  • e.g. they have a sleep thread, and ~~on super crazy fast disks (indeed, my nvme can hit upward of a GB/s)~~ some race condition may be hit

Make even 3 the number of pcs I tried. All of those with a problem are on w10.

[andrewzeitlin]

This happens to me as well. In my experience it seems to occur most often when the files are hosted on a cloud drive (google drive in particular). Could this point toward the source of the issue?

[fuhrmanator]

I confirm that it's not working on a Google Drive (File Stream) in my case with Windows 10. When the PDF file is modified on a true local drive, updating works.

I took a Pandoc project and moved it from Google drive folder to my Downloads folder. I applied my workflow and automatic reloading is working.

[GitHubRulesOK]

@kjk the above different issues are in the main due to secondary non NTFS locations seperate individual problems may be due to using cloud drives / exFAT

One seperate issue is offline/removed network drives (NTFS or not) / redundant file entries

Perhaps consolidate this issue with https://github.com/sumatrapdfreader/sumatrapdf/issues/596 & https://github.com/sumatrapdfreader/sumatrapdf/issues/580

[mirh]

Indeed, nobody before my posts was mentioning network disks.

Btw, I was trying to reproduce the bug "more simply" in a VM (without having to go through installing all the latex cruft).. But somehow using the normal copy command to overwrite files in place isn't enough to make it fail. Sumatra just refreshes as it is expected.

[GitHubRulesOK]

Although it possibly does not help in this case where cached files are apparently not perceived by SumatraPDF as updated in the file system, thus they manually require pressing R to refresh.

It may be useful to know that the upcoming 3.2 release has been updated to increase the locking boundary from 10 Mb to 32 Mb.

SumatraPDF can only be expected generally to monitor and see file changes that affect the file status in the MFT, If you think there are reasonable usage cases where a cloud drive provides a valid signal that can be added for monitoring then please consider providing details by raising an issue at https://github.com/sumatrapdfreader/sumatrapdf/issues?utf8=%E2%9C%93&q=is%3Aissue++sort%3Aupdated-desc+network

[mirh]

I'm saying that aside of the two posts between your and mine, my personal understanding was that this issue was indeed only about changes on a local file system on a local NTFS disk not being detected.

But for me to really pin it down (so it can be understood, and perhaps fixed), I needed to see what was the big deal between my W7 desktop where everything is just fine and my W10 laptop which doesn't work.

... Though you mentioned the MFT now, and after a brief search, I could find out this. Specifically "the usage of copy command modifies one additional timestamp in case of Windows 7 (the entry date timestamp of $STANDARD_INFO)"... so, I don't know. Perhaps there is more to it.

[drjmcauliffe]

I had the same issue when the .tex files were on a USB driver. Moving them on to the laptop solved this for me.

[GitHubRulesOK]

@drjmcauliffe Thanks for your observation, For me using a NTFS usb drive I have not seen an issue, can you confirm if your usb is standard FAT / FAT32 format, rather than NTFS ?

[mirh]

I was having the issue with NTFS. The secret is probably something with either the usb protocol itself, or the usual slower speed of external drives.

[GitHubRulesOK]

@mirh So If I am reading you right for you Windows 10 external NTFS usb drive is not working same as Windows 7 external NTFS usb drive That could explain some user differences (I cannot remember if it was on 7 or 10 that I last tested whilst using LatexTools)

[GitHubRulesOK]

@mirh Sorry to trouble you but I no longer have the current ability to run tests using LatexTools Today's 64bit daily build https://www.sumatrapdfreader.org/dailybuilds.html has an extra ability to detect any mismatch in UAC levels it would be interesting to know if running that version on both 7 and 10 with LatexTools thows up any related error messages. P.S. Sorry again todays build did not complete The next valid one after may take a while :-{

[mirh]

No, I'm saying that I was having this issue with sumatrapdf on a NTFS drive. Therefore, I was guessing some race condition could be involved.

[drjmcauliffe]

@GitHubRulesOK

Thanks for your observation, For me using a NTFS usb drive I have not seen an issue, can you confirm if your usb is standard FAT / FAT32 format, rather than NTFS ?

It's exFAT.

[GitHubRulesOK]

@drjmcauliffe Thanks as that generally would be unsupported

@mirh To be clear are you saying the previous "race" behaviour is no longer a problem?

After yesterdays issues the compiler ran today, so to repeat myself "Sorry to trouble you but I no longer have the current ability to run tests using LatexTools Today's 64bit daily build https://www.sumatrapdfreader.org/dailybuilds.html has an extra ability to detect any mismatch in UAC levels it would be interesting to know if running that version on both 7 and 10 with LatexTools thows up any related error messages.

Are you in a position to use the current daily version and see if any issues occur ?

[Ye-Chao-Liu]

I also meet such a problem on version 3.2 when compiling by VScode. I tried to set both VScode (code.exe) and SumatraPDF.exe as "Run this program as an administrator" in the compatibility settings. This seems useless. It shows [Change detected; refreshing] but nothing changes.

The new version is OK！2020-08-03, commit 66517e5bf34cc289cf400fbab3f9b253383d3d37:

[GitHubRulesOK]

@Ye-Chao-Liu Thanks for feedback, your observation thus sugests it could either be UAC or another recent change makes a difference NOTE there were other changes related to storing changes to settings file in https://github.com/sumatrapdfreader/sumatrapdf/commit/351f73d1e2b8269b3a6262987e72c3ea21727fd0 that may have helped

[mirh]

So.. I have just been testing a W10 vm with both 1803 and 2004. And I can't seem to reproduce the bug (while on the other hand my problematic laptop is on either 1903 or 1909). I suppose none of you reported any change on the other hand?

[GitHubRulesOK]

Hi mirh, I'm glad your feeding back your findings, since in an odd way it helps to know one experienced user can still have two different experiences.

So the norm is compile does work for most users, so honing in on the one that does not work. Distros can differ in OS related behaviour also the version of synctex and the routines it then uses can vary considerably So I have no idea where to look for differences. On compilation there are too many ways to build the PDF to point a finger at one as a culprit. I may have seen multiple failed compiles in my time but the the OP is adamant the compile ran, thus building a fresh synctex that was read by SumatraPDF.exe thus changing synctex triggered a shift in PDF reference. So far so good the page reference worked but at that time the new PDF should have loaded. I see a few possibilities,

1. The synctex update is not working, but the pointers seems to be changing, but anyway that should not stop SumatraPDF reading the new PDF. Key question here is does it update by using R (which it should not need if ReloadModifiedDocuments is set true i.e. the issue)

2. ReloadModifiedDocuments is often reported as not to work in non local \network \ cloud drives. that can most simply be because SumatraPDF has the file committed to memory and is not auto signalled by OS to reload from new cached disk file. Again does pressing R always have / have not the reloaded file.

3)premature signalling SumatraPDF could be triggered that a file change is current but the index at the end of the PDF has not yet been changed. In this case does it change if R is pressed after some delay time.

There are too many possibilities for looking at software differences, but if you have a system that is misbehaving it is easier to look at the synctex / hardware behaviour compared against "with and without" using R

[mirh]

When I said differences, I just meant that "you updated stuff" and now it is working for you. EDIT: well, never mind. I just tried my actual "complete test case" rather than just a quick kludge, and all W10 systems seem to hit this (regardless of disk type)

[mirh]

Ok, I think I can call progress on this. After monitoring yet again the process, I noticed R terminal was doing some odd in-between step with SetRenameInformationFile (yes, I'm not having this problem exactly with sublime). If I compile my doc directly with xelatex instead, the problem doesn't seem to present.

So after following the breadcrumb trail I landed here. And two things standed out: not-so-obvious flags are being used, and W10 1607 did change something in the backend of the function.

When I'll have time I'd finally try to bisect which specific windows version screwed up everything.

[fuhrmanator]

This problem reappeared for me, and I believe I understand more.

If my build process replaces (overwrites) the existing file, Sumatra will reload it. This is how many LaTeX build processes work (I know because, e.g., Adobe Reader will lock a file when you open it, and LaTeX can't overwrite it).

I moved from basic Pandoc to using Quarto.org, which (I think) now deletes the PDF file first at the start of the build. Then, it's re-generated during the build. As such, Sumatra does not automatically refresh it (probably because even though it's the same name, it's not technically the same file).

I'm on Windows. This is possibly the same problem (see https://github.com/SublimeText/LaTeXTools/issues/1373#issuecomment-563263010) since Google Drive deletes and re-creates a file when it syncs it?

[GitHubRulesOK]

@fuhrmanator brilliant observation, so when a file pointer is reused (renewed as RW) it updates, but when a file pointer/handle is deleted/destroyed and replaced in the directory/file allocation with a different file of same name then naturally unless SumatraPDF is informed it hangs onto to the old stable pdf until told manually to R eload R efresh