[ciphershed] Re: Jason Pyeron's Resource planning
- From: Rocki Hack <rocki.hack@xxxxxxxxx>
- To: ciphershed@xxxxxxxxxxxxx
- Date: Fri, 27 Jun 2014 21:36:27 +0200
It's just an prefix for the mount manager unique id for the storage volume.
I don't know if it interfere with system encryption, but for container you
can change it safely
if the volume is not currently mounted.
"Each persistent symbolic link name in the database appears as the name of
a registry value under the *MountedDevices* key accompanied by a *unique ID*.
The unique ID is another unique identifier of a volume (different from the
unique volume name). It helps identify which of the potentially numerous
persistent symbolic link names refer to the same volume."
"Upon receiving a Plug and Play notification of the arrival of a volume
interface, mount manager sends the client three device control IRPs:
*IOCTL_MOUNTDEV_QUERY_DEVICE_NAME*
<http://msdn.microsoft.com/en-us/library/windows/hardware/ff560437%28v=vs.85%29.aspx>
*IOCTL_MOUNTDEV_QUERY_UNIQUE_ID*
<http://msdn.microsoft.com/en-us/library/windows/hardware/ff560441%28v=vs.85%29.aspx>
*IOCTL_MOUNTDEV_QUERY_SUGGESTED_LINK_NAME*
<http://msdn.microsoft.com/en-us/library/windows/hardware/ff560440%28v=vs.85%29.aspx>
"
http://msdn.microsoft.com/en-us/library/windows/hardware/ff567603%28v=vs.85%29.aspx
2014-06-27 20:38 GMT+02:00 Bill Cox <waywardgeek@xxxxxxxxx>:
> On Thu, Jun 26, 2014 at 11:55 PM, Jason Pyeron <jpyeron@xxxxxxxx> wrote:
>
>> > -----Original Message-----
>> > From: Stephen R Guglielmo
>> > Sent: Thursday, June 26, 2014 23:35
>> >
>> > On Thu, Jun 26, 2014 at 3:59 PM, Jason Pyeron
>> > <jpyeron@xxxxxxxx> wrote:
>> > > I have been out of pocket for the past few days, and will
>> > be so until late
>> > > Friday.
>> > >
>> > > * I have only quickly looked at
>> > > https://github.com/CipherShed/CipherShed/pull/11/, is this
>> > being done with a
>> > > search and replace? Lets safety check thinks like #define
>> > WIN32_ROOT_PREFIX
>> > > DRIVER_STR("\\\\.\\TrueCrypt") => #define WIN32_ROOT_PREFIX
>> > > DRIVER_STR("\\\\.\\CipherShed"). I am sure it is fine, but
>> > double checking never
>> > > hurts.
>> >
>> > It was a search and (confirmed) replace, yeah. It was too much to go
>> > through by hand. I used a case-insensitive grep to go through it. I
>> > did, however, commit often and then review each changeset for things
>> > like the strcpy() call in commit d8587c4 (the string length changed
>> > because "CipherShed" is longer than "TrueCrypt."
>> >
>> > Bill also reviewed the changes and posted his response to the
>> > mailing list.
>>
>> Good QA.
>>
>
> Sorry, but I only verified the original sources and added files! I have
> not verified the rebranding patch, but I'm going through it now.
>
> I am having some trouble verifying that we haven't introduced
> backward-compatibility bugs accidentally when we replaced "TrueCrypt" with
> "CipherShed" everywhere. For example, in Driver/Ntdriver.c, line 548, I
> see:
>
> strcpy (volId, TC_UNIQUE_ID_PREFIX);
>
> TC_UNIQUE_ID_PREFIX was changed. I haven't figured out yet if this is
> being compared to existing NTFS volume information or if we just use this
> for a unique ID while running in Windows. If it's just a temp ID, it's no
> problem, but if existing volumes need to match this volId for any reason,
> we may not be able to load them. I need to figure this out.
>
> This is the kind of thing we can test with regression testing. I'll look
> more through this over the next couple of days.
>
> Bill
>
Other related posts:
