Nuxeo Drive - Problem with Drive Edit after a synchronization

Hi, I am using Nuxeo 7.10 with Drive Package 1.5.4 and Drive client 2.1.106. When I synchronize folders, I am no more able to edit with Drive Edit (.docx document). I can only edit the files in the synchronized folders. The synchcronization works well. To reproduce the problem, I suspend the synchronization and add a new document through the web browser. I can Drive edit without problem. I then reactivate the synchronization. At the first attempt to Drive Edit, the document opens. But when I want to save, the “save as” dialog box appears because the file is read only in \AppData\Roaming\SPB_Data.nuxeo-drive\edit.… I cancel the operation and quit without saving. For each other attempts to Drive Edit, nothing happens. Logs are attached.

Is that a problem of configuration on my side?

Thanks !

FILES:   Logs.zip
0 votes

2 answers

848 views

ANSWER

.
01/11/2016



It still fails! Logs are attached (only the client Side)

What I did (step you'll see in the logs): Drive edit a document (Word opened but I got the “save as” dialog box because the file was read-only. I closed Word withtout saving). Drive edit a second time the same document. Nothing happened. Suspended the synchonization I created a new document instance with a new file. Increment the minor version. Drive edit the new document (it was workging). Restart the synchronization. Drive edit the same new document (Word opened but I got the “save as” dialog box because the file was read-only. I closed Word withtout saving). Drive edit a second time the same new document. Nothing happened.

FILES:   Logs2.zip
0 votes



OK, managed to track the problem, it is related to your permission customization: since the user has Read/Write permission but not Remove on the synchronized document, it is synchronized by Nuxeo Drive but flagged as Readonly on the file system (if it wasn't the file would have an inconsistent state, being possibly deleted from the file system and Drive not being able to impact this deletion server-side).

When you Drive Edit the document, which you are allowed to as you have the minimum permission required, Write, Drive detects that the file already exists somewhere inside the Nuxeo Drive folder (under the synchronized folder), so instead of downloading it it copies it from the synchronized folder, this is an optimization. But it also copies the system attributes, in this case Readonly, that's why the file in the .nuxeo-drive/edit/XXX folder is Readonly and you get the error.

This is a specific case but I've done a fix for it within https://jira.nuxeo.com/browse/NXDRIVE-521. Can you please try the latest development build, it includes this fix: http://qa.nuxeo.org/jenkins/view/Drive/job/nuxeo-drive-msi/1301/artifact/dist/nuxeo-drive-2.1.112-win32.msi

Yet, I'm not sure why you are synchronizing the parent folder of these documents because as we can see its files are flagged by Drive as Readonly on Windows so you can only read them, it's one-way synchronization, from the server down to the file system. You don't need to synchronize documents to be able to use Drive Edit on them, it's independent. Drive Edit only requires Nuxeo Drive to be running on the desktop to perform the download, opening of the file, and upload once it's updated.

Hope this help.

01/12/2016

Thanks again ! It is working with the fix included in nuxeo-drive-2.1.112.

I did not pay attention of the level of folder for the synchronization. But I would find the same problem since there is no remove permissions on the leaf folder. As you stated, the Readonly property in Windows is not set in folders that have the Remove permissions. But in our case, we don't want people to have remove permissions. However, it is not a problem for us to remove the Readonly permission on Windows side before editing a file (in addition to lock it in Nuxeo).

I did manipulations with the synchronization and Drive Edit because people will use one method or the other. Without the fix, I would need to enforce only one of both methods.

Finally, I confirm you that facet problem only occurs with previously created documents. On new documents, there is no problem. There is no impact for me since previously created documents are only for test purpose.

Thanks again for your support !

01/12/2016


Thanks a lot for your answer.

On the client side, I have the read/write permission but files are read-only. When I clear the read only property, a drive synchronization cause the files to get back the read-only property.

For the server side. I am not using yet Nuxeo in production. It is actually used in test mode before we deploy it, so I don't have a lot of document instances created. I only customized the write permission to make the remove action available only with the “all rights” permission. What could have cause a facet no more declared by the SchemaManager? It is possible that I tried some packaged from the market place and remove them. I first installed Nuxeo 7.3 and upgrade it with the subsequent versions. The problem on the server side occurs on all documents, even on document instances created with 7.10. Is the problem of the facet no more declared by the SchemaManager but dynamically assigned on a document instance creation can be present on document I create now with 7.10?

Thanks again !

FILES:   Logs2.zip
0 votes



OK, does your user has write permission in Nuxeo on the synchronized folder? That could explain, but then in this case you shouldn't be able to Drive Edit at all (icon should not appear in the web UI)?

The facet issue could be related to previous installlation/uninstallation of marketplace packages, otherwise I don't explain it. For newly created documents on 7.10 it shouldn't happen. If possible I would suggest to drop the database and reinstall Nuxeo from scratch.

01/11/2016

Yes, the user has the write permission. The Drive Edit is working until I start the synchronization. As soon as the first synchronization is done, I cannot edit anymore the document.

On the server side, I am sorry, I mixed the two problems. The Drive Edit problem occurs for all documents. However, it is not the case with the facet one. I had another problem on 1 document the day the log was created. If I remember, that was on a previously 7.10 document creation. I'll do some more test to reproduce this problem and if I still have it, I will drop the database. But that is not my main problem, it is the Drive Edit.

01/11/2016

OK, then for the Drive Edit issue can you please try the following :

  • Quit Drive
  • Delete the $USER_HOME.nuxeo-drive folder.
  • Also delete, if possible, the $USER_HOME\Nuxeo Drive folder, but beware that it will remove all your locally synchronized files, if they are all on the server that shouldn't be an issue.
  • Restart Nuxeo Drive.
  • Configure the log verbosity to TRACE.
  • Connect to the server, this should launch synchronization.
  • Try to Drive Edit a synchronized document.

If it still fails, pleas attach the Drive logs. Thanks.

01/11/2016


Hello,

There are 2 errors:

  • Client-side: indeed we can see a permission issue, can you check that the planglais Windows user has read/write permission on C:\\Users\\planglais\\AppData\\Roaming\\SPB_Data\\.nuxeo-drive and C:\\Users\\planglais\\AppData\\Roaming\\SPB_Data\\.nuxeo-drive\\€dit, though I assume it is the case.
  • Server-side:
    Caused by: org.nuxeo.ecm.automation.OperationException: Failed to invoke operation NuxeoDrive.AttachBlob
    at org.nuxeo.ecm.automation.core.impl.InvokableMethod.invoke(InvokableMethod.java:182)
    at org.nuxeo.ecm.automation.core.impl.CompiledChainImpl.doInvoke(CompiledChainImpl.java:128)
    at org.nuxeo.ecm.automation.core.impl.CompiledChainImpl.invoke(CompiledChainImpl.java:114)
    at org.nuxeo.ecm.automation.core.impl.OperationServiceImpl.run(OperationServiceImpl.java:208)
    ... 121 more
    Caused by: java.lang.NullPointerException
    at org.nuxeo.ecm.core.storage.BaseDocument$Visit.visitBlobsComplex(BaseDocument.java:1020)
    at org.nuxeo.ecm.core.storage.BaseDocument.visitBlobs(BaseDocument.java:960)
    at org.nuxeo.ecm.core.storage.sql.coremodel.SQLDocumentLive.visitBlobs(SQLDocumentLive.java:263)
    at org.nuxeo.ecm.core.blob.BlobManagerComponent.freezeVersion(BlobManagerComponent.java:364)
    at org.nuxeo.ecm.core.storage.sql.coremodel.SQLDocumentLive.checkIn(SQLDocumentLive.java:402)
    at org.nuxeo.ecm.core.versioning.StandardVersioningService.doPostSave(StandardVersioningService.java:272)
    at org.nuxeo.ecm.core.versioning.VersioningComponent.doPostSave(VersioningComponent.java:234)
    at org.nuxeo.ecm.core.api.AbstractSession.saveDocument(AbstractSession.java:1470)
    at org.nuxeo.drive.adapter.impl.FileSystemItemHelper.versionIfNeeded(FileSystemItemHelper.java:49)
    at org.nuxeo.drive.operations.NuxeoDriveAttachBlob.run(NuxeoDriveAttachBlob.java:69)
    
    This is a bug we've just tracked in https://jira.nuxeo.com/browse/NXP-18738 for which the fix will be included in hotfix HF3 for Nuxeo 7.10. Yet you should be able to resolve it without the hotfix: it seems like you have in your database a document instance with a facet that has been dynamically added, yet the facet is no more declared by the SchemaManager. So either you re-declare the facet or you clean up the mixintypes column of the hierarchy table to remove the obsolete facet.

Hope this helps.

0 votes