FolderItem.ShellPath not a shell path when it should be

Targets Windows
1

The docs say:

On Windows, ShellPath returns the short path, if the item exists. Otherwise, ShellPath returns the long path as returned by NativePath.

But I’m seeing a situation where it’s returning the NativePath for a FolderItem where Exists is true. It’s inconsistent between systems. On my own, it’s returning correctly. On some customer systems, it’s returning NativePath.

Besides the file not existing, why else might this be happening? And how can I reliably get a shell-safe path if I can’t rely on ShellPath? I could just use """" + FolderItem.NativePath + """" instead, but that feels like the wrong solution.

2

8.3 alias generation can be disabled on a system-wide or per-volume basis. Check HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\NtfsDisable8dot3NameCreation:

(DWORD)
0 = enable systemwide
1 = disable systemwide
2 = enable/disable per volume (use fsutil.exe to query/set)
3 = like 2, but the system volume is always enabled

1 Like
3

Well that’s frustrating. Would you recommend NativePath wrapped in quotes instead, or something else? And shouldn’t the Xojo framework be doing this automatically? The point is to get a shell-safe path. If it returns something that isn’t shell-safe, that would be a bug in my opinion.

1 Like
4

Quoting the native path is the only way I know of to cover all possible configurations.

1 Like
5

Thanks. That’s what I’ll do then.

6

And feature request for good measure https://tracker.xojo.com/xojoinc/xojo/-/issues/71301

1 Like
7

I wrote about this recently:

I’m not sure the framework ought add the quotes automatically on Windows. For example, if you want to concat something to the end of a ShellPath, auto-added quotes would end up in the middle and would mess things up.

8

Wouldn’t that break a lot of code that is already wrapping the path in quotes? Eg.,

dir “path with spaces” // works
dir ““path with spaces”” // fails with path not found

9

Unfortunately yes, though I don’t know why somebody would be wrapping the shell path.

Correct, but the “right” way to do that is by using FolderItem methods. And if you really wanted to do it this way, use NativePath or just anticipate the quotation mark.

At the absolute minimum, the docs need to be updated with additional reasons this could fail. It’s documented as a means to get a shell-safe path, and doesn’t always do that. As I said in the issue, it should either do what its job or fire an exception. Of all the possible behaviors, this one is pretty wrong.

10

Because they’ve been bit too many times by this.