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!
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 -
Vitaliy Margolen