Skip to content

Bug report: # and % characters are not supported for file commands #4968

@milanholemans

Description

@milanholemans

Priority

(Urgent) I can't use the CLI

Description

Originates from Discord member without GitHub account: https://discord.com/channels/1022486301536178246/1113583852586283059


Almost all spo file and spo folder commands suffer from this issue. The command returns weird responses when a file or folder has a # or % sign in its name.

Example:

m365 spo folder list --webUrl {MY SITE} --parentFolderUrl '/Shared Documents/General/Equipment Data/MiSeq - #0692' --recursive

It always returns an empty result, even where there are child folders.

Even worse, the command is stuck in an endless loop when the parentFolderUrl parameter has a value where a folder starts with a # character (e.g. /Shared Documents/General/Equipment Data/#0692).

Steps to reproduce

Empty result:

  1. Create a folder with a # in its name. E.g. Folder#.
  2. Create a child folder under this folder. E.g. My subfolder.
  3. Run m365 spo folder list --webUrl {MY SITE} --parentFolderUrl '/Mylibrary/Folder#' --recursive

Endless loop:

  1. Create a folder with a name starting with #. E.g. #Folder.
  2. Create a child folder under this folder. E.g. My subfolder.
  3. Run m365 spo folder list --webUrl {MY SITE} --parentFolderUrl '/Mylibrary/#Folder' --recursive

Expected results

Expect the command to return all subfolders recursively.

Actual results

Either an empty result, or no result at all because it's in an endless loop.

Diagnostics

No response

CLI for Microsoft 365 version

v6.9.0

nodejs version

v18.16.0

Operating system (environment)

Windows, Linux

Shell

PowerShell, Debian Linux command line

cli doctor

No response

Additional Info

This is because we use GetByServerRelativeUrl endpoint almost everywhere. This endpoint doesn't support # and % characters at all. We should use GetByServerRelativePath to support these characters. This issue has been noticed for the command spo folder list, but nearly all spo folder and spo file commands use the same (bad) endpoint.

Extra info: https://learn.microsoft.com/en-us/sharepoint/dev/solution-guidance/supporting-and-in-file-and-folder-with-the-resourcepath-api


Agreement

thinking of it... if # is a valid character and we don't support it, then it's a bug that we should fix, in one way or the other. I suggest we don't introduce a new option that we'll remove in 3 months time. That would be introducing unnecessary work. Instead, I suggest we fix it correctly the right way.

We've split the work into 2. This issue is for spo file commands. We'll create another issue for spo folder commands.

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions