#1933 Unable to Save to Dropbox Folder

[Anonymous]

I recently updated to version 2.11.2 on Windows 10. I have latex files on Dropbox that I notice are now unable to save, instead Texstudio creates a new file with a random Letter followed by a number string prefixed to the file name (See image below).

I have downgraded to version 2.11.0 (portable) to test if this was Dropbox or TeXstudio. Version 2.11.0 had no problems saving to my Dropbox folder and did not create any new files.

I notice that this appears in the Changelog:

• fix: show a warning if file could not be saved
  But no warning occurs, the file is not saved and a new file is created (TeXstudio shows that the file is unsaved, so it knows it has not saved the file).

Is anyone else able to replicate this? I am using a feature of ShareLatex to sync latex projects with my dropbox.

I will be downgrading until this problem can be addressed.

[Jon]

An update: The portable version is able to save, but version 2.11.0 installed version is not.

This feels like it might be a permissions thing.
Questions:

1. Why is there a new file being created?
2. Why is there no warning about the file being unable to save?
3. How is the portable version able to save but the installed version not?

[Tim Hoffmann]

1. Overwriting a file on disk has an inherent risk of loosing data if something goes wrong. The correct approach is: Write a temporary file. If that succeeds remove the original file and rename the temporary file. Before 2.11.0 we used our own proprietary implementation for this. From 2.11.0 on, we switched to a standard Qt mechanism using QSaveFile.

2. In 2.11.0 there was no warning because that was not implemented. In 2.11.2 there should be. We'll have to investigate why it's not the case.

3. I do not understand that. The portable version is binary identical to the installed version. Please check in the about dialog if the version (including hg revision) and the used Qt versions are the same.

Dropbox interacts with the file system for synchonisation. It might be that this interferes with the accessibility of files or the above mentioned method of saving files. That needs to be tested. However, I don't have Dropbox installed right now, so it will take some time before I can look into this.

[Jon]

Update: the portable version does have the problem, but it seems that sometimes the problem does not show up. This occured when I first tested the portable code, but after shutting down my computer the problem showed itself in the portable self.

I am downgrading to TeXstudio 2.10.8 (hg 5804:967c6023de2d) until the problem is fixed.

You might want to look at the code where you call commit (http://doc.qt.io/qt-5/qsavefile.html#commit) on the QSaveFile. It states that if a write error occurs then it will delete the temporary file and return false, otherwise it renames the temporary file. In either case there should be no temporary file left behind, but I have shown that the tempory file stays on the system. Maybe dropbox prevents files from being created and deleted too quickly (a small delay might fix this)?

[Tim Hoffmann]

1. Indeed, there was a case, in which no warning was issued. fixed: hg 6237 (64d26300d919)

But still that does not explain why saving fails in the first place. Investigation still required.

@ Temporary file: If commit() promises to leave no temporary file no matter if successful or not, this is likely a bug or false documentation.

[Tim Hoffmann]

I've now setup a dropbox for testing, but I still cannot reproduce this issue.

• Are you using your own dropbox folder or is the folder shared by someone else?
• Do you have write permissions to the folder?

[Jon]

• I own the dropbox folder
• I have write permissions. The problem only appears in the code versions using QSaveFile.

I noticed that on my laptop, running texstudio v2.11.2, I do not have this problem even though it is working in the same configuration of dropbox folders. The only difference I can see from my laptop to my desktop are the following:

• Desktop is running texstudio on SSD and dropbox is stored on HDD. Laptop is all on SSD.
• Desktop's dropbox folder is using Windows File History (https://support.microsoft.com/en-us/help/17143/windows-10-back-up-your-files).

I recently tried TeXstudio 2.11.2 (hg 6192:72f68414a729) (portable) on 2 files, both that have Windows File History enabled.

• main.tex - This file was not in a dropbox folder. RESULTS: saved perfectly normal
• main-in-dropbox-app.tex - This file was in dropbox APP folder. RESULTS: unable to save
• main-in-dropbox.tex - This file was in the root dropbox folder. RESULTS: unable to save
• After Pausing Dropbox - The above results are able to save

[Tim Hoffmann]

To sum up so far (please correct if I misunderstood something):

• the effect is limited to dropbox folders
• the effect does not always happen in dropbox folders (the additional conditions are still unclear)
• if it happens, saving is possible after pausing dropbox

What if you resume dropbox after pausing. Does saving break again or does it keep working?

[Jon]

• Correct
• It occurs on my main computer if dropbox is running
• Correct
  If I pause and then resume, saving is still broken.

[Tim Hoffmann]

You wrote that your main computer is using Windows File History.

First: Does it happen on non-dropbox folders which are on the same drive and also using Windows File History?

If so: Is there any chance you can test the dependency on dropbox+Windows File History that?
i.e. deactivate Windows File History (don't know if that is possible) or move the dropbox folder to another drive that is not using Windows File History. Or inversely activate Windows File History on your laptop and test if it breaks the previously working configuration.
I know these are deeper modifications to your setup and you should decide if you want to do them. On the other hand, we have to narrow the possible cause. And dropbox+Windows File History is currently the best guess.

[Jon]

To answer your first question: I am able to save tex files that exists outside of Dropbox (on the same drive that my dropbox folder is located).

I turned off File History for that folder and texstudio was still unable to save.

---

A quick fix would be to have an advance option added to allow for switching between using the old code and the new QSaveFile code. If you are unable to replicate this error on your side, I know that debugging is going to be a lot of back and forth.

[doncherry]

I have this problem as well and it is bugging me pretty badly, see attachment ... (The (2) etc. were attached only as a consequence of me moving the files to another directory, so not by TeXstudio.)

I noticed that when I try hitting Ctrl+S, the file is usually save after the third attempt. And yesterday, when I closed TeXstudio, I saw the process still running and keeping one CPU at 100% for several minutes until I terminated it. I’m using TeXstudio 2.11.2 (hg 6192:72f68414a729) Using Qt Version 5.6.1, compiled with Qt 5.6.1 R on Win7-64 with Dropbox 13.4.21.

I’ll try downgrading with a portable version, so I should be able to try other things with 2.11.2 if that could be of any help, and if I can spare the time at the moment.

Edit: It’s probably no surprise, but I can confirm that the problem does not appear with TeXstudio 2.10.8 (hg 5804:967c6023de2d) Using Qt Version 5.5.1, compiled with Qt 5.5.1 R – (portable). By the way, a big thank you to the TeXstudio team for being so mindful as to a) provide the older versions and b) making it so convenient to transfer settings from one TeXstudio installation to another. There really is a reason (or probably several dozen) why TeXstudio is my favorite editor!

[Bananach]

Same issue

TeXstudio 2.11.0 (hg 6062:c58c915d7759)
Using Qt Version 5.5.1, compiled with Qt 5.5.1 R
Windows 7 Pro (v6.1.7601 SP 1)
Dropbox v13.4.21 Professional Account

As with others, first two saves fail and produce copies, third save succeeds.

(just copying the info from https://sourceforge.net/p/texstudio/discussion/907840/thread/10e8debe/?limit=25)

[U_Fischer]

There are two reports on tex.sx regarding temporary files filling up dropbox:
http://tex.stackexchange.com/questions/336541/i-need-to-compile-a-few-times-and-a-bunch-of-weird-auxiliary-files-appear-in-my
http://tex.stackexchange.com/questions/336594/texstudio-or-miktex-problem-extra-files-not-the-normal-ones

[Yannic Meyer]

Same issue here with files saved within dropbox-folder. Will be happy to provide further information or test fixes if needed.

TeXstudio Version 2.11.2-win-qt5.6.1
Windows 10 pro, File history active
Dropbox Version 13.4.21

I temporarily got rid of the issue by downgrading to TeXstudio 2.10.8.

[Yingxiang Yang]

Same issue here with files saved within dropbox-folder. Will be happy to provide further information or test fixes if needed.

TeXstudio Version 2.11.2-win-qt5.6.1
Windows 7 Enterprise Service Pack 1
Dropbox Version 13.4.21

I temporarily got rid of the issue by downgrading to TeXstudio 2.10.8.

[Henri S]

I also have this issue.

TeXstudio 2.11.2 (hg 6192:72f68414a729) Using Qt Version 5.6.1, compiled with Qt 5.6.1 R
Windows 7 Home Premium SP 1 (build 7601)
Dropbox version 13.4.21

[Legge]

Laptop: texstudio v2.11.0; Dropbox Version 13.4.21; Windows 7 Pro and Dropbox on same SSD but on different partitions (C: and D:) - No Problems
Desktop: texstudio v2.11.0; Dropbox Version 13.4.21; Windows 7 Pro on SSD (C:) and dropbox on HDD (D:) - Have the mentioned problem with the temporary files. Sometimes the save works as expected but mostly I have to try three times.

Dropbox

[Tim Hoffmann]

I've uploaded a development snapshot:
https://sourceforge.net/projects/texstudio/files/texstudio/TeXstudio%20development/texstudio-2.11.3-dev-hg6281-win-qt5.6.2.exe/download

There's now an option Options -> Advanced Editor -> Special Options -> Safe writing of files. Deactivating this restores the old (<2.11.0) way of saving files.

[doncherry]

Thanks for the fast fixing, the saving option works!

This version, however, has introduced a new bug related to \todo{foo}-notes and the way they’re displayed in the structure tree. This document:

\documentclass{article}
\usepackage{todonotes}
\newcommand{\glyph}[1]{#1}
\begin{document}

\(x\)\todo{Foo}

\glyph{a} \glyph{a} \glyph{a} \glyph{a} \glyph{a}\todo{x}

\end{document}

leads to 3 + 6 todo notes in the structure tree (instead of 2, see attachment), so the problem seems to be related to backlashes preceding \todo.
I’m using Win7-64 and "TeXstudio 2.11.3 (hg 6281:f89ef8a4cfbd) This is a development version. Using Qt Version 5.6.2, compiled with Qt 5.6.2 R".

[Tim Hoffmann]

Indeed this is a bug. But it already shows up in 2.11.2. Since it's not related, I've transfered it to a separte bug report: https://sourceforge.net/p/texstudio/bugs/1970/

[Jaime Beneyto]

Hello Tim,

First of all, thank you for your kind support.

I downloaded and installed your dev version, but the option you mention is not there under "Special Options".

Also, during installation of this .exe when selecting whether to create a desktop icon or not the install wizard goes back to the first "select language" prompt and starts over.

[Jacob]

I was also having the same problem saving to a Dropbox folder. After updating to the dev snapshot and unchecking the Safe writing of files option the issue went away.

More interestingly, though, is that without unchecking this box the dev snapshot version now gives the appropriate warning. The warning is:

<file path>
Could not be written. Error (10): The process cannot access the file because it is being used by another process.
.
If the file already existed on disk, it was not modified by this operation.

[Tim Hoffmann]

More interestingly, though, is that without unchecking this box the dev snapshot version now gives the appropriate warning.

That's to be expected. I've added the warning as well :). Anyway, thanks for the confirmation of the proper error message.

[Tim Hoffmann]

bug reported upstream to Qt: https://bugreports.qt.io/browse/QTBUG-57299

[Usman Saeed]

The RC version texstudio-2.12.0-rc does the trick. I don't see the safe save option but now the irksome nonsaving is gone!
When is the stable version expected?