To try to implement copy-paste for shell folders, I used SHFileOperation for the actual copy. SHFileOperation calls SHChangeNotify to notify listeners about changes to the file system. But I noticed that the shell view would not update correctly if it was at 'C:' but it would if it was at '/home/user_name/.wine/drive_c/'. In the end I traced this to the fact that in the first case the shell view calls SHChangeNotifyRegister with a pidl of the form <Desktop|My Computer|C:> while SHFileOperation is using SHChangeNotify to send a notification to those listeners registered on pidls of the form <Desktop|/|home|user_name|.wine|drive_c>. This makes it such that the shell view doesn't always get the notifications it expects. I can think of a couple of ways to fix this.
1. Have SHChangeNotifyRegister normalize all file system pidls to ones rooted in the unixfs. 2. Have the shell view register on a unixfs pidl.
I would like to know if either of these is a good solution, or if there are better solutions. I can also write a quick test to demonstrate the problem if necessary.
-- Jay Yang
On 06/24/2011 12:27 PM, Jay Yang wrote:
To try to implement copy-paste for shell folders, I used SHFileOperation for the actual copy. SHFileOperation calls SHChangeNotify to notify listeners about changes to the file system. But I noticed that the shell view would not update correctly if it was at 'C:' but it would if it was at '/home/user_name/.wine/drive_c/'. In the end I traced this to the fact that in the first case the shell view calls SHChangeNotifyRegister with a pidl of the form<Desktop|My Computer|C:> while SHFileOperation is using SHChangeNotify to send a notification to those listeners registered on pidls of the form<Desktop|/|home|user_name|.wine|drive_c>. This makes it such that the shell view doesn't always get the notifications it expects. I can think of a couple of ways to fix this.
- Have SHChangeNotifyRegister normalize all file system pidls to ones rooted in the unixfs.
- Have the shell view register on a unixfs pidl.
I would like to know if either of these is a good solution, or if there are better solutions. I can also write a quick test to demonstrate the problem if necessary.
I ran into a similar problem with IShellFolder::AddFolder. That's commit 0a55ec2c9e1dc5fd0b99ad1202fd7849b0187808 which was for Bug 18606. Maybe that will help you? Just popped into my head when I saw your email...
Andrew
On 06/24/2011 03:55 PM, Andrew Eikum wrote:
On 06/24/2011 12:27 PM, Jay Yang wrote:
To try to implement copy-paste for shell folders, I used SHFileOperation for the actual copy. SHFileOperation calls SHChangeNotify to notify listeners about changes to the file system. But I noticed that the shell view would not update correctly if it was at 'C:' but it would if it was at '/home/user_name/.wine/drive_c/'. In the end I traced this to the fact that in the first case the shell view calls SHChangeNotifyRegister with a pidl of the form<Desktop|My Computer|C:> while SHFileOperation is using SHChangeNotify to send a notification to those listeners registered on pidls of the form<Desktop|/|home|user_name|.wine|drive_c>. This makes it such that the shell view doesn't always get the notifications it expects. I can think of a couple of ways to fix this.
- Have SHChangeNotifyRegister normalize all file system pidls to ones rooted in the unixfs.
- Have the shell view register on a unixfs pidl.
I would like to know if either of these is a good solution, or if there are better solutions. I can also write a quick test to demonstrate the problem if necessary.
I ran into a similar problem with IShellFolder::AddFolder. That's commit 0a55ec2c9e1dc5fd0b99ad1202fd7849b0187808 which was for Bug 18606. Maybe that will help you? Just popped into my head when I saw your email...
Andrew
While it is a similar issue, it doesn't quite work, because in this case the code I would have to change lies in SHFileOperation. If I were to change SHFileOperation to work as in your code, it would solve the issue for the 'C:' type drives, but the issue we currently have there would appear in the unixfs folders. This is because to call SHFileOperation, unixfs converts the unix path to a dos path, so the notifications would go out to the wrong listeners again.
The other possible solution that I forgot to mention is to implement IFileOperation, which accepts pidls as arguments. and then use this instead of SHFileOperation. But I'm worried about using IFileOperation in shell folders since MSDN says that IFileOperation cannot be used in a multithreaded apartment (MTA) context, but I don't think we can make any assumptions about the apartment model in shell folders. If I'm wrong on that last point, please correct me, I'm really not certain on that.
-- Jay Yang
-
Andrew Eikum -
Jay Yang