File deleted while being edited not saved

[mvvvmd]

Nextcloud version 20.02 Onlyoffice version 6.0.2-5 Onlyoffice connector: 6.1.0

Steps to reproduce:

• Create a new document in Nextcloud
• Edit the document
• In a second browser window/tab delete the file
• Edit the document
• Close the document
• Recover the document from the trash
• Open the Document, changes after the deletion are lost.

What should happen:

The user should receive a message there is a problem saving and a resolution should be offered without loosing data.

Background:

We had a user loosing all changes from a single edit session. The file was listed in NC activities as deleted by the user. The user had closed the document about half an hour after the deletion and had no indication saving had not worked. No error messages just "all changes saved" as normal.

The file was recovered from the user trash but without the changes from the edit session. In the Nextcloud and OnlyOffice logs file not found errors where discovered. The file with the changes was recovered from the OnlyOffice server cache.

[CarlOnlyoffice]

Hello @mvvvmd Could you please specify the exact location where you found the file? Was it the /forgotten/ subdirectory in DS cache directory?

What errors have you discovered in converter/out.log and docservice/out.log of the Document Server?

[mvvvmd]

The file was recovered from "/var/lib/onlyoffice/documentserver/App_Data/cache/files/3984990626_8091/output.docx"

Below the log entry, I've removed user details and changed the domains. This is the moment I think the user closes the doc, OO does register "Files not found" but does not inform the user about this and the data is not synced back to Nextcloud.

[2020-12-02T14:07:10.156] [ERROR] nodeJS - sendServerRequest error: docId = 3984990626;url = https://nextcloud.ourdomain.org/index.php/apps/onlyoffice/track?doc=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VySWQiOiIzNDcyNzNjMC05ZTg3LTEwMzYtOTM3NC02YjM0OTYyMWEyNTUiLCJmaWxlSWQiOjY4OTE4MCwiZmlsZVBhdGgiOiJcL0NPVklELTE5XC91aXRzbGFnZW4gcGVpbGluZ2VuIG5vdjIwMjBcL2JlcmljaHQgaW50cmFuZXQgbmF2IHBlaWxpbmdyZXN1bHRhdGVuLmRvY3giLCJzaGFyZVRva2VuIjpudWxsLCJhY3Rpb24iOiJ0cmFjayJ9.NsYggkwsoN7WNTqnpU9RV1kjBOnO8O0L4QecjzPmhpc;data = {"key":"3984990626","status":2,"url":"https://onlyoffice.ourdomain.org/cache/files/3984990626_8091/output.docx/output.docx?md5=i2861v_qwKp_qoOjX8P0PQ&expires=1606915331&disposition=attachment&filename=output.docx","changesurl":"https://onlyoffice.ourdomain.org.nl/cache/files/3984990626_8091/changes.zip/changes.zip?md5=R6VRM70duFxcJke79NKjtw&expires=1606915331&disposition=attachment&filename=changes.zip","history":{"serverVersion":"6.0.2","changes":[{"created":"2020-12-02 10:55:35", USER DETAILS REDACTED}],"lastsave":"2020-12-02T12:39:25.107Z","notmodified":false} Error: Error response: statusCode:404; headers:{"date":"Wed, 02 Dec 2020 13:07:10 GMT","server":"Apache","strict-transport-security":"max-age=15768000; includeSubDomains; preload","referrer-policy":"no-referrer","x-content-type-options":"nosniff","x-download-options":"noopen","x-frame-options":"SAMEORIGIN","x-permitted-cross-domain-policies":"none","x-robots-tag":"none","x-xss-protection":"1; mode=block","set-cookie":["ocabqv2zlb4o=jggo7huvuvlhjtc06nmo2ne4r6; path=/; secure; HttpOnly; SameSite=Lax","oc_sessionPassphrase=b24OBrP%2FuQr1fjRWs4mK8wS49nk52euHpAJxQGcH%2FIAzAY0isea6qI8IFSURerm%2BjxTdt8oG8QifWX8zFfVMtbvjmBem%2FQpRYxKPzrlJ%2BDHlsplA9BD8j9sPWYdTEQtM; path=/; secure; HttpOnly; SameSite=Lax","__Host-nc_sameSiteCookielax=true; path=/; httponly;secure; expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=lax","__Host-nc_sameSiteCookiestrict=true; path=/; httponly;secure; expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=strict"],"expires":"Thu, 19 Nov 1981 08:52:00 GMT","cache-control":"no-cache, no-store, must-revalidate","pragma":"no-cache","content-security-policy":"default-src 'none';base-uri 'none';manifest-src 'self'","feature-policy":"autoplay 'none';camera 'none';fullscreen 'none';geolocation 'none';microphone 'none';payment 'none'","content-length":"29","keep-alive":"timeout=5, max=100","connection":"Keep-Alive","content-type":"application/json; charset=utf-8"}; body: {"message":"Files not found"} at Request._callback (/snapshot/server/build/server/Common/sources/utils.js:0:0) at Request.init.self.callback (/snapshot/server/build/server/Common/node_modules/request/request.js:185:22) at Request.emit (events.js:198:13) at Request.<anonymous> (/snapshot/server/build/server/Common/node_modules/request/request.js:1154:10) at Request.emit (events.js:198:13) at IncomingMessage.<anonymous> (/snapshot/server/build/server/Common/node_modules/request/request.js:1076:12) at Object.onceWrapper (events.js:286:20) at IncomingMessage.emit (events.js:203:15) at endReadableNT (_stream_readable.js:1143:12) at process._tickCallback (internal/process/next_tick.js:63:19)

[CarlOnlyoffice]

@mvvvmd are there any storeForgotten entries in the logs?

[mvvvmd]

Yes, right below the previous log entry.

2020-12-02T14:07:10.160] [WARN] nodeJS - storeForgotten: docId = 3984990626

[CarlOnlyoffice]

So in this case there is no data loss. Document saving is performed after all users close the editor tab, so there can be no indication in the editor about correct/failed saving. During editing, we work with the file in Document Server's cache, so when the user adds changes to the file, they will see 'all changes saved' caption. It means the changes are saved in Document Server's database. When the editing session is over, Document Server builds a file and then tries to send it to the storage, but in your case the original file was deleted, so DS couldn't send it back. For cases when the storage is unavailable for some reason during file saving, there is a special directory in DS cache - forgotten. Files in this directory are not deleted when the cache is cleared, so you can always get this file there.

You can enable the 'keep intermediate versions while editing' option in the connector settings, so in the case like this (file removed from the storage), an attempt to manually save the file will trigger an error that will offer a user to use "Download As" option to ensure no data is lost.

[mvvvmd]

I understand what you are saying but from the user perspective the data is gone. They recover the deleted file from trash and the changes are not there. The admin can recover the file (not easy) but this in my experience means the user lost trust in the application already.

If the file cannot be saved as expected by the end user the application needs to help the user prevent loosing access to the data. I cannot stress enough how important this is, they will lose trust and use competitor products instead. There can never in no instance be even the appearance of data-loss to the user, the UI should always communicate to the user when such problem arises and offer a resolution like saving a copy for instance. We have also seen similar issues when user internet connections drop out.

I've tested 'keep intermediate versions while editing' before, this is a bad user experience in it self as it does not auto save among things.

I really hope you can take steps to remedy the way the application handles these things. We enjoy using OO en are working hard to keep our users onboard to keep doing so.

[ImaCrea]

Hello there, we're facing similar issue here also. I totally support @mvvvmd on his analysis of how important it is to fix this bug.

Any news maybe on that side @LinneyS please ?

[yllekz]

I think I encountered an issue like this just yesterday. I was working on a file and saved it regularly, only to find that the file was entirely deleted when I attempted to open it the next day. The file is still listed in the recent items but it seems OnlyOffice completely deleted it.