"Save-document" failures due to Dropbox syncing - other's affected?

[KlausB]

I have been seeing save-failures for documents saved in Dropbox, due to a short-term file-lock after closing file handles. Since Dropbox support has said "its an issue with the program, not with our client", I am searching for people who have also experienced this issue or anything related.

Technical details. After writing a file and closing the associated file handle, there seems to be a short time window where Dropbox retains a file lock, thus preventing file operations from other programs. To the best of my knowledge, this time window is extremely short, as Dropbox caches files before processing them for upload.

Now, programs commonly don't overwrite user documents directly, as this would cause a loss of data, if for some reason the write operation cannot finish cleanly. Instead they write to a temporary file, and then replace the old file with that temporary file.

In combination I have seen this cause write-failures, specifically with LyX (#10091). Since I was also able to reproduce the issue with a python script, I consider the root cause to be unfavorable behavior in the Dropbox client, as the "write temporary file, rename within fractions of a second" pattern is quite common. If there are other programs affected by the issue, it would probably help to convince Dropbox, that there is an issue.

Note that solving such issues is usually out of the hands of the Dropbox user, unless they want to get into reprogramming their software.

This issue is probably specific to Windows, since Unix-based operating systems typically don't disallow renaming or deleting files with open file handles, due the "inode" abstration separating file contents from their position in the directory hierachy.

[Lusil]

Sorry to hear that, @KlausB. 

The first thought that ran through my mind was to give a reinstall of the desktop app’s latest stable version (68.4.102) a try and ensure that your Dropbox folder is located within a location that’s on the same hard drive as your OS.

You also mention that you’ve contacted the third party app in question, in which case, please do let us know of any updates. In the meantime, I’ll leave this thread open for other users who may have had a similar experience to share any feedback. 

Thanks in advance!

[KlausB]

@LusilIs there any particular reason for keeping the Dropbox folder on the OS drive? I generally try to minimize the amount of user data there.

[Lusil]

Thanks for getting back to me on this, @KlausB. 

In general, it’s recommended to choose a location that’s on the same hard drive as your OS because the desktop app won't work correctly if the Dropbox folder becomes inaccessible. This can happen if it's located on an external drive that gets disconnected. You can find more info regarding this here. 

Hope this helped to some extent. 

[Rich]

The important thing is that it's on an internal drive, and not an external or removable drive. Dropboxers just seem to assume that the OS drive will be the only internal drive in a person's computer.

Personally, mine is located on a dedicated SSD, which is the third of four internal drives in my system.

[KlausB]

Same for me (laptop). OS and application data is on a 128 GB m2 SSD, user data on a larger 2.5" SATA SSD. Putting the dropbox folder on the OS drive is a (bad) option, but wouldn't be if I were using more storage than provided by the free tier.

Given the nature of the issue, and its occurrence across multiple PCs, and that it becomes negligibly infrequent for small files, it is almost certainly caused by the timing of Dropbox's caching: The program (Ly releases its file-lock by closing the file-handle, and Dropbox is caching the file the short moment later, when the program tried to perform the "rename FILE.XXXXXX.lyx to FILE.lyx" operation. The issue only really started appearing with my PhD-thesis, as before all files were too small and/or other programs do SOMETHING different, when applying the "write temp, then rename" pattern.

Hence why I am looking for cases of other programs being affected.

From the bug-report for LyX, I know at least that other USERS are affected.

[Lusil]

Thanks for the detailed reply, @KlausB. 

I understand how important this is for you, so I’ve made sure to pass your comments along regarding this. As mentioned previously, I’ll also leave this thread open for any other users that may have encountered this too.

In the meantime, please let us know of any updates and if you have any other questions, don’t hesitate to get back to us. Thanks in advance once again!

[KlausB]

Apparently the issue has previously been encountered by other programs. I found the following in the configuration dialog of TexStudio:

The issue has also come up in the bugtracker of the QT library.

https://bugreports.qt.io/browse/QTBUG-57299

It is closed, but comments indicate, that it isn't solved.

[Olshaj]

I have now had two days where I have not been able to save a PowerPoint presentation to Dropbox without it locking up my computer. I have restarted it and tried closing both PowerPoint and dropbox and still have a current issues where it tries to save the dropbox icon says it indexing the PowerPoint thing but then it just locks on indexing I need to have this resolved urgently. Thank you

[Lusil]

Hey there @Olshaj, sorry to hear that. 

Could you please provide me some additional info on this? For example:

• Are you getting any error messages when trying to save the file to your Dropbox folder? 
• Does this occur with a specific file or are you getting the same behavior with other files too?

Additionally, could you please send me a screenshot (without any personal info) of what the Dropbox icon that’s next to your computer’s clock shows when you click on it?

Thanks in advance!