I know this is no new topic, and I found some old remarks on the Xojo forum. But I am either unable to translate them or whatever …
The story so far: A Windows Desktop app starts an internal Xojo Web app and the browser. This works fr most. But not all. Some customers have spaces in their folder name, and when their system truncates them by adding ~1 after the first few characters, everything is fine.
If it does not, trouble is programmed, at least when started from the internal disk. The shell will either quit with error code 1, telling me the path could not be found, or even worse:
If the user removes the spaces from the folder the app rests in and tries again, the shell will run but my mutex window will show. The web app has no mutex, so the app behaves as if another instance of it would be started instead.
From an USB stick everything will work ok on the same system. I thought it would be an old system, but both failing and succeeding systems are Win 10 Build 18363.
Any hints on how to escape a Windows shell path successfully? Or how to handle this anyway?
And any ideas why the Mutex might get triggered? The shell path clearly ends with the Webserver app name, not with the desktop app name.
Dont use a shell ? 
The WFS has declares for the Win32 API to start a new process that takes a path with or without spaces + params
Well, I hoped someone would introduce me to the secrets of Windows path handling, but certainly a workable hint. Thanks!
Think I’ll rather try WindowsProcessMBS instead – just found it by chance in the vast documentation.
Windows paths arent so bad as they can be quoted and escaped much like Unix ones
Just there are more things to escape so I prefer to NOT have to deal with having to do that at all
Plus there are things you cant do via a shell very well that can be done using the Win32 API
That said here’s a decent guide
https://ss64.com/nt/syntax-esc.html
MS has something written up as well but like so many things I cannot find it right this second
Have you tried enclosing the path in double quotes?
1 Like
Yes, I did.
The adventure continues: I thought I’d move the helper to AppData/Roaming which I am using anyway for some preferences.
Folderitem.CopyTo: No problem on a Mac.
FolderItem.CopyTo: No error on Windows. No copied folder too.
!!!**???
Ah! Found this.
Not a bug when the documentation says the opposite?
feedback://showreport?report_id=40133
Odd
Based on comments in the case it seems as if there used to be a note about this only working on macOS
But yeah I would ask that case be reopened