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.
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.
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.
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.
It is closed, but comments indicate, that it isn't solved.
The way we work is changing. Share and discover new ways to work smarter with Dropbox in our community.Sound good? Let's get started.
For more info on available support options, see this article.
If you found the answer to your question, please 'like' the post to say thanks to the user!