EldoS | Feel safer!

Software components for data protection, secure storage and transfer

GetOriginatorProcessName() problem with device path

Also by EldoS: Rethync
The cross-platform framework that simplifies synchronizing data between mobile and desktop applications and servers and cloud storages
#30817
Posted: 09/25/2014 14:49:52
by Todd Gleason (Standard support level)
Joined: 09/11/2014
Posts: 21

I'm trying to use GetOriginatorProcessName() and seeing paths like this:

Code
C:\Device\HarddiskVolume2\Windows\explorer.exe
C:\Device\HarddiskVolume2\Program Files (x86)\...

Is this the correct behavior? It appears to be a combination of drive letter ("C:"), device path ("\Device\HarddiskVolume2"), and file path, rather than just the straight-up file path I expected.

To untangle this it looks like I need to read the drive letter, get its device path with a P/Invoke call to QueryDosDevice(), and remove that from the returned path (if it is indeed present, not sure if it is all the time). It just seems strange because I don't know that I've seen this combination of paths before (I've seen device paths + file paths, but not with the drive letter.), which made me wonder if this was the intended behavior.
#30818
Posted: 09/25/2014 16:08:54
by Todd Gleason (Standard support level)
Joined: 09/11/2014
Posts: 21

OK, that was a mistake; the C: got pre-pended when .NET threw a DirectoryNotFoundException. It's just a pure device path, which makes more sense (though it's more painful to deal with).
#30827
Posted: 09/26/2014 07:30:29
by Volodymyr Zinin (EldoS Corp.)

GetOriginatorProcessName() returns name in the Windows native format. As a variant we can add to the next build an auxiliary API which will convert win32 path to the NT-format (actually such method exists internally in CBFS).
#30939
Posted: 10/09/2014 09:50:10
by Todd Gleason (Standard support level)
Joined: 09/11/2014
Posts: 21

This doesn't matter much to me as we just leveraged some code from another project to do this. It's a little tricky because we don't want to impede performance, while at the same time supporting real drives, drive mappings (involving LanmanRedirector), and UNC paths (involving Mup or LanmanRedirector). Thankfully we had to solve this years ago for a different project and ended up using a prefix tree (trie) to do such matches and conversions efficiently.

I expect others would be very interested in such an API, though. If you add it, please reference it from the GetOriginatorProcessName() docs and explain what GetOriginatorProcessName() does because it probably won't be clear to developers who have never heard of device paths.

Reply

Statistics

Topic viewed 1212 times

Number of guests: 1, registered members: 0, in total hidden: 0




|

Back to top

As of July 15, 2016 EldoS Corporation will operate as a division of /n software inc. For more information, please read the announcement.

Got it!