sumatrapdf
sumatrapdf copied to clipboard
sumatrapdfreader
File tracking failure occurs when a different file with the same name directly replace the original one.
I noticed that when a file with same name was moved to cover the on-tracked file, SumatraPDF did not regard it as an update. However, under any other cases, the tracking procedure works fine. It really fuzied me as my xelatex driver always generates new PDF via a move-and-cover method and then, the viewer won't be refreshed.
I consider it as an syscall limitation. But if it is possible to fix the bug internally, it can be a great deal!
Depends how a file is rebuilt, traditionally LaTeX.pdf under 10 MB were auto refreshed on re compile, the limit should now be 32MB there are system factors that can delay the signal to refresh such as other file interference by AntiVirus or File Syncronisation outside SumatraPDF control.
Silly example externally file was changed (same filename) by replace with icon in fresh position and SumatraPDF auto refreshed simply on that external reposition.
Can you provide a reproduction steps, preferably one that doesn't use xelatex but some simple way to reproduce the problem?
Can you provide a reproduction steps, preferably one that doesn't use xelatex but some simple way to reproduce the problem?
Simply generate pdf A under folder T, and PDF B under folder G via any methods (note that B differs from A). Open A in the SumatraPDF then execute shell e.g. `mv -f G/B.pdf T/A.pdf' - no changes in the SumatraPDF after that.
I found only latexmk with xelatex driver sometimes performs like this, while others work well.
Typing "R" (refresh) is a workaround, but I confirm this problem happens in my Quarto builds (latex is used under the hood, but the quarto build process deletes the PDF at the start, and so when it's rebuilt it is technically a new file).
Note that Quarto has its own PDF previewer via a web interface (it starts up a web server running on localhost and you open the PDF in a browser). So updating works, more or less, but I find it clunky especially when the localhost port changes. For these reasons, I prefer SumatraPDF.
This sounds awfully similar to the problem I documented in https://github.com/SublimeText/LaTeXTools/issues/1373. It used to work before W10 1709.
It really fuzied me as my xelatex driver always generates new PDF via a move-and-cover method and then
That could explain why latex tools are so special and nobody else in the hell seems to notice. I wonder if some slightly different implementations of the same we use here are also affected?
p.s. FWIW my testcase is running through tinytex a thesisdown document in RStudio (which comes with sumatra built-in btw)
@kjk again I am reminded this issue has tones of the refresh problems encountered by some LaTeX users in recent https://github.com/sumatrapdfreader/sumatrapdf/issues/3774 so is it a common file replacement mis detection ?
Isn't #3774 about something bad/undesired happening after refresh happens, as opposed to refresh not happening at all?
@kjk I notice that moving file (or mv command) only causes a FILE_ACTION_ADDED notion. But sumatrapdf do nothing with it. May be let sumatrapdf treat FILE_ACTION_ADDED just same as FILE_ACTION_MODIFIED in line
if (notify->Action == FILE_ACTION_ADDED || notify->Action == FILE_ACTION_MODIFIED ||
notify->Action == FILE_ACTION_RENAMED_NEW_NAME)
It seems worked, but I am not sure will this cause any other iusse else.
@changlichun makes sense. probably won't break anything. Would you like to make a PR?