UnixFolder_IShellFOlder used instead of SHELL32_IShellFolder

[Vitaliy Margolen]

For some reason now UnixFolder_IShellFOlder is used in some cases where
SHELL32_IShellFolder should of been used instead.

If you look at the sheel32/test/shlfolder.c test_EnumObjects_and_CompareIDs it
should use the real IShellFolder. But for some reason it's being replaced by
UnixFolder_IShellFOlder. Any ideas why this is happening? I thought that it
should be it's own shell name space (different ID)?

This could be a main cause for all the problems people having with browsing
files. As now you can "escape" to the root (/) dir. That should not be possible
for windows programs!

-- 
Best regards,
 Vitaliy

[Michael Jung]

Hi Vitaly,

On Tuesday 01 November 2005 19:35, Vitaliy Margolen wrote:
> For some reason now UnixFolder_IShellFOlder is used in some cases where
> SHELL32_IShellFolder should of been used instead.

That's how it is supposed to work. If unixfs is registered in the namespace at 
the desktop, the desktop shell folder forwards to CLSID_UnixDosFolder instead 
of CLSID_ShellFSFolder in it's ParseDisplayName method. The corresponding 
code is in shfldr_desktop at line 189. Conceptually, that should'nt be a 
problem though, since CLSID_UnixDosFolder objects should be compatible to 
CLSID_ShellFSFolder. Do you have a concret problem with that?
> If you look at the sheel32/test/shlfolder.c test_EnumObjects_and_CompareIDs
> it should use the real IShellFolder. But for some reason it's being
> replaced by UnixFolder_IShellFOlder. Any ideas why this is happening? I
> thought that it should be it's own shell name space (different ID)?

Let's say c: maps to /home/mjung/.wine/drive_c and an application passes "C:
\windows" to the DesktopFolder's ParseDisplayName method. If unixfs is 
enabled, shfldr_desktop will forward to UnixFolder::ParseDisplayName, which 
will create a SHITEMIDLIST like home::mjung::.wine::drive_c::windows. This 
means you will see the unix path in the file dialog. If you call 
GetDisplayName on the corresponding folder object, you will get "C:\windows" 
again. In a nutshell, unixfs' SHITEMIDLISTs are based on fully qualified unix 
paths, while the display names (and thus the usual "string'ified" paths) are 
drive based DOS paths. That's why you can use unix paths in file dialogs of 
applications, which weren't meant to work with unix paths. Does this 
explanation make sense? I guess I'll have to write up some documentation on 
unixfs.
> This could be a main cause for all the problems people having with browsing
> files.

I wasn't aware that people do have a lot of problems with browsing files. Did 
I miss something on wine-devel (or wine-user), or was this discussed on IRC? 
Can you give me some pointers?
> As now you can "escape" to the root (/) dir. That should not be 
> possible for windows programs!

Actually, you can't. OpenFile, CreateFile and the like are still based on DOS 
paths. It's only deep inside shell32, that the unix api's are called to 
browse the unix filesystem. Everything that goes in and out are DOS paths.

Bye,
-- 
Michael Jung
mjung(a)iss.tu-darmstadt.de