Prev: update CDialog region in a user defined message handler
Next: Determine if "this" process is running with administrative privileges
From: Jackie on 16 Jun 2010 07:06 Jackie wrote: > Jackie wrote: >> This looks pretty useful to me! > > It hit me just now... I guess that wasn't what you originally were > looking for, and I've been trying to help regarding that.. But I was > looking in the wrong direction. Silly me. > I was thinking that you could use those APIs instead of dealing much with those native paths. But I guess you're not really trying to get a process' image file name at all so it might be useless to you. :) -- Regards, Jackie
From: nki00 on 16 Jun 2010 18:51 > I was thinking that you could use those APIs instead of dealing much with > those native paths. But I guess you're not really trying to get a process' > image file name at all so it might be useless to you. :) > > -- > Regards, > Jackie Thanks. I still need to test those APIs before I can comment. I appreciate your input though...
From: Jackie on 16 Jun 2010 19:06 nki00 wrote: > Thanks. I still need to test those APIs before I can comment. I appreciate > your input though... I have tested the APIs (but not on Windows 2000 yet) and they do seem to work well. But then again, if that wasn't what you were originally looking for, it doesn't matter much if you test it or not. My bad for getting excited and doing too much. Haha. :) -- Regards, Jackie
From: nki00 on 17 Jun 2010 02:29 > I have tested the APIs (but not on Windows 2000 yet) and they do seem to > work well. But then again, if that wasn't what you were originally looking > for, it doesn't matter much if you test it or not. My bad for getting > excited and doing too much. Haha. :) > > -- > Regards, > Jackie No, thanks A LOT, Jackie! I do appreciate your help. And yes, I tested those APIs and they do work. But, there's still one issue in the code I was using. I don't know if you know this API: MoveFileEx(FileName, NULL, MOVEFILE_DELAY_UNTIL_REBOOT); It marks a file for deletion during the next system reboot. For that it places the file path into this registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations but, at least on my WinXP SP3, it doesn't check if the file is already there and simply adds it to the bottom of the list (reg value of the type REG_MULTI_SZ). My program may be calling this API many times over on the same file thus this list may grow pretty large and I obviously do not want to slow down the end-user machine that may run my software. So I was thinking to write a small wrapper function that will check if a file path is already there and if so it won't add it again. So that was my intention. Unfortunately the system adds files into that registry key in that weird kernel format, so to compare them I need to translate them into a "normal" format. So that's where my current road block is. At the moment I'm simply removing that \??\ prefix and everything works fine, but I believe that that is not an accepted way to do it.
From: Jackie on 17 Jun 2010 05:37
nki00 wrote: >> I have tested the APIs (but not on Windows 2000 yet) and they do seem to >> work well. But then again, if that wasn't what you were originally looking >> for, it doesn't matter much if you test it or not. My bad for getting >> excited and doing too much. Haha. :) > > No, thanks A LOT, Jackie! I do appreciate your help. And yes, I tested those > APIs and they do work. I don't mean to make it sound like I deserve it but.. Thanks, nki00. I am happy if I could help. > But, there's still one issue in the code I was using. I don't know if you > know this API: > > MoveFileEx(FileName, NULL, MOVEFILE_DELAY_UNTIL_REBOOT); > > It marks a file for deletion during the next system reboot. For that it > places the file path into this registry key: > HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session > Manager\PendingFileRenameOperations > > but, at least on my WinXP SP3, it doesn't check if the file is already there > and simply adds it to the bottom of the list (reg value of the type > REG_MULTI_SZ). My program may be calling this API many times over on the > same file thus this list may grow pretty large and I obviously do not want > to slow down the end-user machine that may run my software. So I was > thinking to write a small wrapper function that will check if a file path is > already there and if so it won't add it again. So that was my intention. > Unfortunately the system adds files into that registry key in that weird > kernel format, so to compare them I need to translate them into a "normal" > format. So that's where my current road block is. At the moment I'm simply > removing that \??\ prefix and everything works fine, but I believe that that > is not an accepted way to do it. > I haven't used the MOVEFILE_DELAY_UNTIL_REBOOT flag, but I have some thoughts on how to do this without digging into the registry yourself. How about creating a temporary file which indicates that you have already scheduled the file(s) for deletion? And you can use MoveFileEx on this file as well. You could probably even avoid using MoveFileEx by scheduling a batch script or something to run at system startup to delete that/those files. I learned that \??\ is used for long paths. Around 32k characters is the max limit instead of the normal MAX_PATH (260). -- Regards, Jackie |