`spo file add`: A file or folder with the name already exists

[MartinLoeper]

Priority

(Urgent) I can't use the CLI

Description

I want to replace a remote sharepoint file using the spo file add command, but the server complains that the file already exists.

Steps to reproduce

m365 spo file add \
        -u "xxxxxx" \
        --folder "xxxxxx" \
        --checkOut \
        --checkInComment 'mloeper locked file to modify entries' \
        --path "some local path"

Expected results

The file should be replaced. Since it is versioned, a new version should be added.

Actual results

{"error":"Eine Datei oder ein Ordner mit dem Namen \"xxxxx\" ist bereits vorhanden."}

aka "file already exists".

Diagnostics

No response

CLI for Microsoft 365 version

v7.6.0

nodejs version

20.11.1

Operating system (environment)

Linux

Shell

zsh

cli doctor

No response

Additional Info

No response

[Adam-it]

Thanks for rising the issue. We will look into it ASAP

[milanholemans]

Hi @MartinLoeper, how large is the file you are trying to add? Is it over 250MB?

[milanholemans]

Hi @MartinLoeper, could you give some more details about what you are trying to achieve with what kind of file? Seems like I can't reproduce this error.

---

While looking at the command, I found some other issues as well:

• Verbose logs only work in debug mode
• Undoing a check-out of a file always fails since there is no access token provided to the request.
• Impossible to check in a file using a site relative URL, for example: --folder "/Shared Documents".

Already made a fix for these issues, if I can reproduce the issue, I'll update the PR with that fix as well.

[MartinLoeper]

Hi @MartinLoeper, how large is the file you are trying to add? Is it over 250MB?

It's about 35 kB. So no, not nearly 250 MB

[MartinLoeper]

Hi @MartinLoeper, could you give some more details about what you are trying to achieve with what kind of file? Seems like I can't reproduce this error.

While looking at the command, I found some other issues as well:

• Verbose logs only work in debug mode
• Undoing a check-out of a file always fails since there is no access token provided to the request.
• Impossible to check a file using a site relative URL, for example: --folder "/Shared Documents".

Already made a fix for these issues, if I can reproduce the issue, I'll update the PR with that fix as well.

Do you think your changes already solve the issue? Should I give it a try by checking out your PR?

Thanks for looking into this so quickly!! :rocket:

[MartinLoeper]

Hi @MartinLoeper, could you give some more details about what you are trying to achieve with what kind of file?

We are basically sharing an encrypted file in sharepoint. So my usecase is to download the file, edit it and to upload it again. Since the file is versioned, each upload creates a new version. The Sharepoint UI in the browser always asks what to do and we press "replace", which creates a new version.

I am currently automating this workflow using m365 cli and the following commands: spo file get and spo file add. I guess, I should add another one: spo file checkout before doing the get to be even more safe?

[milanholemans]

Thank you for giving a bit more context.

This is how I tested the command (in PowerShell):

m365 spo file add -u $webUrl --folder "/Testlib" --checkOut --checkInComment "Lorem ipsum dolor sit amet" --path $filePath

And this is giving me this as a result (I executed it a few times):

I am currently automating this workflow using m365 cli and the following commands: spo file get and spo file add. I guess, I should add another one: spo file checkout before doing the get to be even more safe?

If you provide the --checkOut flag, we will check out your file before starting the upload, and check it back in again when it's finished. So technically you shouldn't need spo file checkout.

[milanholemans]

Do you think your changes already solve the issue? Should I give it a try by checking out your PR?

Please do! I'm a bit in doubt if this will fix your issue, but we can always try. Are you familiar with testing PRs locally, or should I provide some help?

[MartinLoeper]

Do you think your changes already solve the issue? Should I give it a try by checking out your PR?

Please do! I'm a bit in doubt if this will fix your issue, but we can always try. Are you familiar with testing PRs locally, or should I provide some help?

I just checked out your branch and ran my command using --debug flag. This showed a lot of helpful stuff. In particular, the --folder parameter was pointing the remote file path instead of the file's basedir. Thus, the error message I got was misleading. It was masquerading a 404 error which was thrown earlier by checkout.

Thanks for leading me into the right direction @milanholemans!

[milanholemans]

Aw, I see, so that means your issue is fixed now? If that's the case, I can have a look at it so we throw a clearer error instead of this misleading one.

[milanholemans]

@MartinLoeper did you by any chance had the time to answer my previous comment?

[MartinLoeper]

Not yet sorry, I am OOO this week and back next Monday.

[milanholemans]

@MartinLoeper if you have some time in the coming days, please could you verify my previous comment?

[MartinLoeper]

Looks like my issue is fixed now. I think this issue can be closed :)

If that's the case, I can have a look at it so we throw a clearer error instead of this misleading one.

If you have any idea how to do that, it would be immensely helpful for people like me who misuse the cli :D