command 'ls' not working in directory containing spaces

[HashtagMarkus]

The ls command is not working in directories like documents and settings

The response from the beacon is

      ERROR: Access to the path '.\*' is denied.

[bats3c]

Have you tried putting the directory in quotes?

[HashtagMarkus]

Yes, here's how it doesn't work

shad0w(Administrator@NINJUTSU-OS) ≫ cd "C:\Documents and Settings"
[i] Beacon (5cd2c86b80b78d8a158483817b777e16) received task
Directory Changed to: 'C:\Documents and Settings'

shad0w(Administrator@NINJUTSU-OS) ≫ ls
[i] Beacon (5cd2c86b80b78d8a158483817b777e16) received task
ERROR: Access to the path '.\*' is denied.

while on other dirs it works

shad0w(Administrator@NINJUTSU-OS) ≫ cd C:\Go
[i] Beacon (5cd2c86b80b78d8a158483817b777e16) received task
Directory Changed to: 'C:\Go'

shad0w(Administrator@NINJUTSU-OS) ≫ ls
[i] Beacon (5cd2c86b80b78d8a158483817b777e16) received task
Directory: .\*

Type    Created           Last Access        Length      Name
----    -------           -----------        ------      ----
DIR     16/03/2020 05:26  24/09/2020 07:36               .
DIR     16/03/2020 05:26  24/09/2020 07:36               ..
DIR     27/07/2020 11:53  24/09/2020 07:36               api

[bats3c]

This is strange, will have a look into it

[bblenard]

@HashtagMarkus Does C:\Documents and Settings\ actually exist. I looked at this in my test machine and found that cd "C:\Documents and Settings\" works fine however C:\Documents and Settings doesn't actually exist. I'm wondering if this is some strange windowism that lets you SetCurrentDirectory without failing but since you aren't actually in a real directory you can't read the contents of the directory which is why the ls call fails.

EDIT: I should have been more specific. C:\Documents and settings does exist however it isn't a normal directory. It is a junction and that would probably explain the behavior.

C:\>dir /a
 Volume in drive C is Windows 10
 Volume Serial Number is C436-9552

 Directory of C:\

02/08/2020  06:31 PM    <DIR>          $Recycle.Bin
02/09/2020  03:16 AM    <DIR>          $SysReset
02/08/2020  06:39 PM    <DIR>          BGinfo
09/04/2020  03:10 AM    <DIR>          Boot
09/27/2018  04:47 AM           394,984 bootmgr
03/18/2017  08:57 PM                 1 BOOTNXT
02/09/2020  03:16 AM             8,192 BOOTSECT.BAK
03/23/2017  04:14 PM    <JUNCTION>     Documents and Settings [C:\Users]

Also since FindFirstFile provide information about the junction itself instead of the destination that would explain why we get the invalid handle when trying to ls the junction

"If the path points to a symbolic link, the WIN32_FIND_DATA buffer contains information about the symbolic link, not the target" https://devblogs.microsoft.com/oldnewthing/20100212-00/?p=14963