You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In my company, we are using mountainduck to mount nextcloud folders as drive letters on windows 10.
If 2 or more persons open the same file at the same time, and save it, the file get corrupted. We see a 0 KB file, and can't open it anymore.
Worse, file versions are also corrupted :
And when I try to put back the good file in that place, with same name (after restoring file from backup) :
via webdav it's not possible, if I put back the file and erase the corrupted one, the new file get corrupted again
via nextcloud desktop client : idem
via nextcloud web interface : that way it works, I can replace the corrupted file with the new one, and it stays in place.
Mountainduck includes a functionality to lock office files when they are already opened by a user, but it doesn't work for other kind of files.
Bug seen on windows 10 with mountainduck, but seems to be a webdav bug, it should probably appear with other webdav clients and other OS (needs tests).
Steps to reproduce
Map a nextcloud folder as a drive letter on windows on at least 2 computers
Open the same file simultaneously on the 2 computers, modify it and save it both ways.
Try to open it again, via webdav or on nextcloud's web interface, you should see a 0 KB file
On nextcloud's web interface, look at previous versions, they're also corrupted
Try to replace the corrupted file by a good file, with same name, by webdav or nextcloud desktop client : it doesn't work, the file get still corrupted and 0 KB.
Expected behavior
Don't loose files when there are simultaneous access on files.
I see some ways to solve that, in order of preference :
implement locking documents via webdav in nextcloud. This way, it would not be possible for 2 persons to open simultaneously the same document with write access
find a way to handle a conflict, like nextcloud webdav client does
keep the last saved version, but without corrupting the file. And ideally keep all versions in version tab, so that there is no data loss.
Installation method
Other Community project
Nextcloud Server version
26
Operating system
Debian/Ubuntu
PHP engine version
PHP 8.1
Web server
Nginx
Database engine version
MySQL
Is this bug present after an update or on a fresh install?
None
Are you using the Nextcloud Server Encryption module?
tomdereub
changed the title
[Bug]: webdav access with drive letter (windows) - file corrupted when edited simultaneously
[Bug]: webdav access with drive letter (windows) - file corrupted in 0 byte file
Aug 3, 2023
Bug description
In my company, we are using mountainduck to mount nextcloud folders as drive letters on windows 10.
If 2 or more persons open the same file at the same time, and save it, the file get corrupted. We see a 0 KB file, and can't open it anymore.
Worse, file versions are also corrupted :
And when I try to put back the good file in that place, with same name (after restoring file from backup) :
Mountainduck includes a functionality to lock office files when they are already opened by a user, but it doesn't work for other kind of files.
Bug seen on windows 10 with mountainduck, but seems to be a webdav bug, it should probably appear with other webdav clients and other OS (needs tests).
Steps to reproduce
Expected behavior
Don't loose files when there are simultaneous access on files.
I see some ways to solve that, in order of preference :
Installation method
Other Community project
Nextcloud Server version
26
Operating system
Debian/Ubuntu
PHP engine version
PHP 8.1
Web server
Nginx
Database engine version
MySQL
Is this bug present after an update or on a fresh install?
None
Are you using the Nextcloud Server Encryption module?
None
What user-backends are you using?
Configuration report
List of activated Apps
Nextcloud Signing status
Nextcloud Logs
Additional info
Nextcloud 26.0.4 installed on yunohost 11.2.3.
The text was updated successfully, but these errors were encountered: