Home / Google: Drive File Stream breaks ReloadModifiedDocuments

On a fully updated Windows 10 machine with google drive file stream, the latest version of sumatrapdf doesn’t detect modified documents on the google drive and reload them automatically.

My work flow is to keep my latex files on my google drive on my local machine and edit them there. In this situation, the pdf file generated by latex is also on the google drive. Sumatra has no trouble rendering the pdf, but, since I moved to the google drive, sumatra no longer notices changes. I now have to hit the ‘r’ key to get the reload. Don’t get me wrong, it’s still waaayyyy better than the alternatives, but I wanted to let developers know in case there’s an easy fix.

I have also confirmed that if I do this on my local drive, non google drive, that the auto reload still works. It’s definitely something to do with the pdf being on the google drive. My guess is that it’s actually google’s fault, possibly not correctly updating timestamp information, but maybe not, or maybe there’s a workaround?

Thanks for a great pdf viewer!

Albert

Just to follow up. I looked at the timestamps as reported by the ‘ls’ function in Windows PowerShell and they do show that the “LastWriteTime” is being updated on the pdf when I re-latex, at least to the nearest minute. I waited a minute after a write to see if sumatra would notice the change and it didn’t.

One thing to consider is that many apps including SumatraPDF may not “see” changes to remote encrypted files. There has been at least one reported problem where the Master file SumatraPDF constantly monitors for changes (SumatraPDF-settings.txt) IF on an EFS drive is thus not updated.

The files in this situation are stored and modified on a local partition. Behind the scenes, the google drive file stream client handles synchronizing the local files with the the “master” google copies (remote cloud storage).

I don’t think there’s any encryption, at least not on the local storage.

That said, my grasp of the google drive filesystem client/server relationship etc is largely speculative. Thanks for the input.

My experience with latex and synctex is weak but I don’t think SumatraPDF is monitoring the files per se, I may be wrong but I recollect it seems to be triggered by the forward / reverse calls. You say that when the files are fully local, the behaviour is affected by the presence of stream handling, that suggests google drive software is somehow interfering in or masking the normal two way communication.

Another related issue may be the format of the synctex file as the relative location in the header can be problematic i.e. the format was initially designed for nix and can thus have wrong number or slant of slashes (or reference a device location rather than local windows drive)
It may be worth comparing the first part of that file in each case.

Ensure drive steam is from January this year version : 25.157.165.2150 or later since there were issues with windows and pdf files prior to those fixes (and of course you may still be finding more)

I’m using latex (miktex), but not sure what synctex is. I just edit the .tex file with vim and generate the pdf file with pdflatex. I only experience the sumatra issue when I do this within a google drive folder. If I’m somewhere else on the local hard drive, all is well.

My drive stream version is:
Google Drive File Stream
Version: 26.1.42.2151

Thanks again.

SyncTeX is a utility written by Jérôme Laurens which enables synchronization between your source document and the PDF output. If your editor/viewer supports it, then you can click in your source and jump to the equivalent place in the PDF or click in the PDF and it will jump to the appropriate place in your source document. This is generally what allows SumatraPDF to sync with Latex editors, along with the way one calls the other to say there is a change.

The mechanism is controlled by files that hold the location of lines in both .pdf and .tex for synchronisation, by default they needed to be alongside the .pdf but more recently can be elsewhere, the key here is that they hold the location of the other file in the pair.

sounds interesting, old dog here, been using vim and command line since around 1994, maybe time for a change, haha

miktex pdflatex should be building other index files for the .pdf it is generating are there yourfile.synctex either alongside yourfile.pdf or somewhere in the miktex directories ?
the may be zipped .gz files

NOTE they may be set to be deleted when miktex closes ,so you need to use explorer whilst miktex is active to see if they are alongside the local.pdf but NOT alongside otherLocation.pdf
EQUALLY the type could be a problem as Drive Stream may be handling .gz differently

PS been using DOS since mid 80’s so there’s still hope for you, Young Padawan

I am really appreciating for developing and providing the wonderful PDF viewer.

On a fully updated Windows 10 machine with google drive file stream, the latest version of sumatrapdf doesn’t detect modified documents on the google drive and reload them automatically.
I have also confirmed that if I do this on my local drive, non google drive, that the auto reload still works. It’s definitely something to do with the pdf being on the google drive.

Yes, I have the same problem.
The version of Sumatra is 3.1.1.

Hiroyuki

There are three old legacy issues and only one fix at play here that mean the usual suggestion to test latest version (portable copy would do) may not make a difference, but you never know

The DailyBuilds are only 64bit so if you are using older 32bit system would need to follow link there to pre-release.

The LaTeX related “fix” is support for larger pdfs so improves support from <10MB to <32MB which can be one problem. Conversely the better version for font support was usually 3.1.2 (which works up to 10MB max) but ymmv.

the other two “problems” are

1. synctex component expects to be run on local windows drives
   (This blocks some WSL/nix users unless they work around that)

2. traditionally any “virtual” hard drives such as USB volumes need to be seen as if they behave similar to remapped local drives with NTFS format (this may be where those google drives fall down)