Problems with uploading documents to Shared Business Folders when shared folder exists on a SharePoint site #1345
Labels
Comments
|
Synchronizing of locally edited ms-office files misbehaves too
|
rzck
changed the title
rzck
changed the title
|
@rzck When uploading Microsoft files to OneDrive (and this is more prevalent when using SharePoint Libraries) - Microsoft will take that upload, modify it by adding metadata to it. When they add the metadata, they remove the file, then put it back - its a feature. As such, this is why:
Unfortunately, the only thing that can be done here is for you to complain to Microsoft. For further details, refer to OneDrive/onedrive-api-docs#935 - but it is interesting that you are seeing this on a 'shared business folder' - but most likely this is coming from a SharePoint site - thus - this is why this issue is impacting you. |
|
@rzck
This would give you the further details as provided above that links the feature of SharePoint to this particular quirk of using OneDrive and Microsoft documents. |
|
@rzck |
|
eh thanks for the reply |
|
@rzck |
|
@abraunegg |
If I can work out to reproduce this (which I have tried this morning and I cannot) - essentially I would have to make code changes blind for your issue, but test them locally to ensure nothing has broken, then get you to test to see if the issue is worked around. This really is a Microsoft SharePoint issue which is the root cause here ... it is their bug that should be fixed - or at least the OneDrive API fixed to work around this issue. |
|
That would be cool - if you think it is worth your time, it seems to me it could be a bit corner case... |
abraunegg
added a commit
that referenced
this issue
Mar 17, 2021
…or Business Shared Folders * In looking on how to fix #1345, it appears that for some reason the logic behind syncing shared folders was not working (although it previously was). Update the logic to specifically check the DB for the required driveId & itemId before attempting to get that DB item.
abraunegg
added
Bug
abraunegg
changed the title
It is an interesting issue, but not really a corner case - as, a realistic expectation would be that a SharePoint library folder could be shared with a user .. thus, the same issue as what happens (OneDrive/onedrive-api-docs#935) is going to occur. I am just surprised however that this use case has taken up until now to surface. Anyhow - I can now actually replicate this issue, which means I can also test any fix that I am working on before asking you to validate. |
|
@rzck To run the PR, you need to run the client from the PR build directory: When running the PR, your version should be: The PR still needs work to clean it up, but, from my testing, this is able to work around the SharePoint bug where uploaded files are modified by Microsoft, thus, technically making your upload void which is the root cause of this issue. |
abraunegg
added
PR Provided - Needs Testing
Waiting on Response
and removed
In Progress
|
@rzck |
|
@abraunegg |
|
@rzck For OpenSuSE Leap 15, these were: For Tumbleweed which you are running, you may need to massage these to work. At a minimum:
Additionally, instead of all the D lang repo's from above, install via the actual DMD RPM file for SuSE: I do not have an OpenSuSE environment running at the moment, so unable to give you more direct instructions here |
|
@abraunegg |
|
@abraunegg Unfortunately, modifying already added folder does not work ideally. |
|
@abraunegg |
This is 100% normal for working around the problem caused by SharePoint.
This is not normal - and this error message is what occurs when using 'master' and not the PR - refer to this in the PR as my testing results. Can you please double check that you are running the right binary :) When running the PR version you have to:
If you are running the right binary / application PR version, can you please send through a verbose debug log as per this process - archive and send via email. Below is a new test to validate using a XLSX file & your folder structure: Without --verbose: With --verbose: As you can see - the modified XLSX file is uploaded without issue. Please can you double check what binary file you are running to ensure you are running the right version. |
|
@rzck Modified file uploaded without issue Now .. if I go back to using the current 'master' - I get this exact scenario you are detailing:
Application Output: |
|
@rzck |
|
@rzck |
1 similar comment
|
@rzck |
abraunegg
added
Closed: Lack of Response
|
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Hi,
I have this issue: when I try to upload changes or newly created files in ms-office format (.xlxs, .docx etc) I got this error:
Uploaded file size does not match local file - upload failure - retryingonedrive is then stuck with retrying to upload - you have to interrupt syncing manually
oddly, the folder is eventually uploaded - I can see it and use it from the Onedrive browser interface
No problem like that with other formats (.ods , .pdf, .dwg whatever I tried works just fine)
It only happen with shared folders
Application and Operating System Details:
onedrive --display-configIs your configured 'sync_dir' a local directory or a network mount point?
local
What partition format type does your configured 'sync_dir' reside on? Output of:
lsblk -fsync_dir resides on nvme0n1p5
It is company provided office365 account, I use Onedrive on my desktop (win10) and laptop (openSUSE), usually not simultaneously, the shared folder is within company' sharepoint
To Reproduce
Steps to reproduce the behavior if not causing an application crash:
onedrive --synchronize --sync-shared-foldersComplete Verbose Log Output
A clear and full log of the problem when running the application in the following manner (ie, not in monitor mode):
Bug Report Checklist
The text was updated successfully, but these errors were encountered: