Didn't we just leave this party?
So once again, we're buying a house. Sort of.
A two-bedroom townhouse in Normanhurst. Lovely gas kitchen, roomy living areas, small but servicable bedrooms, bright and breezy, and generally lovely. Stretching our budget ever so slightly, but possible.
We put in an offer at the bottom of the vendor's range. They've accepted grudgingly, which is good, because we couldn't go any higher. We've done inspections - it's pest free, trouble free, the only complaint the body corporate seems to have made is that the carwash over the fence plays loud music on weekends, and this unit is a fair way away from all that. If that's the worst of their troubles, then it sounds like a peaceful sort of block.
There are some units within the complex owned by the Housing Commission. Given the above complaint made by the strata corporation, it seems to me that they're not especially rough Housing Commission. However, the bank's valuation of the property wasn't as kind. Their valuation was $60,000 less than the amount we offered.
Good thing we haven't handed over any money yet. So we either have to renegotiate the sale at a much reduced price (don't know how well the vendors will react to that), or give up on this one (because the bank won't finance it for that price, and we'd be buying it for too much anyway).
So it's on hold again until we get this sorted out.
In other news, I've been learning everything I ever wanted to know about the NT device management subsystem at work. Extremely geeky dissertation follows:
Ext2Fsd does a reasonably good job at implementing an IFS driver for Ext2 filesystems. Its control panel program is quite awkward, however, so we've decided to write something that does what we need instead. Unfortunately, for reasons I haven't ascertained just yet (due to not wanting to debug kernel-mode drivers unless I absolutely have to), the driver doesn't implement the MOUNTED_DEVICE interface, so Windows doesn't automatically attach the drives to the filesystem. It also doesn't list them when you enumerate the available volumes on the system, either via FindFirst/NextVolume() or SetupDiGetClassDevsEx( &GUID_DEVINTERFACE_VOLUME, ... ).
How do you attach a drive letter to a volume without being able to query the system to find if it exists?
The answer is in the NT Object Manager. Amongst other things, this keeps a list of mappings of names to devices - you can query it to find out that C:\ maps to \Device\HarddiskVolume1 for instance. The commands QueryDosDevice() and DefineDosDevice() allow access to these mappings. If you know a valid device name, you can attach a letter to it. There's a cool little tool that allows you to manually inspect the contents of the Object Manager namespace (WinObj), and using that I found out that there's a complete set of links for each partition on each drive, and that the Ext2 drives appear in there. Perfect, I thinks! I can just examine the \Device\ directory for harddrives, compare them against the list of mounted drives, and assign drive letters for ones that aren't mounted.
Except the \Device\ directory is out of bounds to mere mortals. QueryDosDevice() is the only way into the Object Manager, and it only allows you to read the GLOBAL directory. Some net searching turns up the information that there are some undocumented functions in NTDLL.dll that allow access to the full namespace (which is how WinObj and the existing Ext2Fsd control panel program do it).
So the round-about way (not wanting to try undocumented calls just yet either) is:
* Call QueryDosDevice() for PhysicalDriveN, where N is an integer >= 0. Stop when it returns a non-valid mapping.
* For each drive X,
* Query the Drive Layout
* For each Partition returned
* Check that the PartitionNumber > 0 (a drive with 1 partition returns 4 structures with 3 partition 0s... I don't quite get it)
* For each real partition Y
* Hack together a string \Device\HarddiskX\PartitionY
This string is a name that seems to always be valid in the namespace, and can be mounted. Of course, you don't know for sure which drive is which, because the \Device\HarddiskX\PartitionY -> HarddiskVolumeZ mapping is kept in the hidden part of the ObjectManager. And assuming that for a system with 2 partitions they will be HarddiskVolume1 and HarddiskVolume2 respectively is wrong, as removable drives leave their HarddiskVolume link behind when they're removed.
So given this Partition string, you can query the partition details and given certain conditions be sure that it's a recognised partition type, but not a Windows specific one. Using the Cygwin port of e2fsck, you can ascertain that it's a valid filesystem (or repair it if it wasn't unounted cleanly) and then finally assign it a drive letter. Success!
Now, if I could just stop having dreams about filesystem internals - I've been looking at this for 2 weeks straight!
A two-bedroom townhouse in Normanhurst. Lovely gas kitchen, roomy living areas, small but servicable bedrooms, bright and breezy, and generally lovely. Stretching our budget ever so slightly, but possible.
We put in an offer at the bottom of the vendor's range. They've accepted grudgingly, which is good, because we couldn't go any higher. We've done inspections - it's pest free, trouble free, the only complaint the body corporate seems to have made is that the carwash over the fence plays loud music on weekends, and this unit is a fair way away from all that. If that's the worst of their troubles, then it sounds like a peaceful sort of block.
There are some units within the complex owned by the Housing Commission. Given the above complaint made by the strata corporation, it seems to me that they're not especially rough Housing Commission. However, the bank's valuation of the property wasn't as kind. Their valuation was $60,000 less than the amount we offered.
Good thing we haven't handed over any money yet. So we either have to renegotiate the sale at a much reduced price (don't know how well the vendors will react to that), or give up on this one (because the bank won't finance it for that price, and we'd be buying it for too much anyway).
So it's on hold again until we get this sorted out.
In other news, I've been learning everything I ever wanted to know about the NT device management subsystem at work. Extremely geeky dissertation follows:
Ext2Fsd does a reasonably good job at implementing an IFS driver for Ext2 filesystems. Its control panel program is quite awkward, however, so we've decided to write something that does what we need instead. Unfortunately, for reasons I haven't ascertained just yet (due to not wanting to debug kernel-mode drivers unless I absolutely have to), the driver doesn't implement the MOUNTED_DEVICE interface, so Windows doesn't automatically attach the drives to the filesystem. It also doesn't list them when you enumerate the available volumes on the system, either via FindFirst/NextVolume() or SetupDiGetClassDevsEx( &GUID_DEVINTERFACE_VOLUME, ... ).
How do you attach a drive letter to a volume without being able to query the system to find if it exists?
The answer is in the NT Object Manager. Amongst other things, this keeps a list of mappings of names to devices - you can query it to find out that C:\ maps to \Device\HarddiskVolume1 for instance. The commands QueryDosDevice() and DefineDosDevice() allow access to these mappings. If you know a valid device name, you can attach a letter to it. There's a cool little tool that allows you to manually inspect the contents of the Object Manager namespace (WinObj), and using that I found out that there's a complete set of links for each partition on each drive, and that the Ext2 drives appear in there. Perfect, I thinks! I can just examine the \Device\ directory for harddrives, compare them against the list of mounted drives, and assign drive letters for ones that aren't mounted.
Except the \Device\ directory is out of bounds to mere mortals. QueryDosDevice() is the only way into the Object Manager, and it only allows you to read the GLOBAL directory. Some net searching turns up the information that there are some undocumented functions in NTDLL.dll that allow access to the full namespace (which is how WinObj and the existing Ext2Fsd control panel program do it).
So the round-about way (not wanting to try undocumented calls just yet either) is:
* Call QueryDosDevice() for PhysicalDriveN, where N is an integer >= 0. Stop when it returns a non-valid mapping.
* For each drive X,
* Query the Drive Layout
* For each Partition returned
* Check that the PartitionNumber > 0 (a drive with 1 partition returns 4 structures with 3 partition 0s... I don't quite get it)
* For each real partition Y
* Hack together a string \Device\HarddiskX\PartitionY
This string is a name that seems to always be valid in the namespace, and can be mounted. Of course, you don't know for sure which drive is which, because the \Device\HarddiskX\PartitionY -> HarddiskVolumeZ mapping is kept in the hidden part of the ObjectManager. And assuming that for a system with 2 partitions they will be HarddiskVolume1 and HarddiskVolume2 respectively is wrong, as removable drives leave their HarddiskVolume link behind when they're removed.
So given this Partition string, you can query the partition details and given certain conditions be sure that it's a recognised partition type, but not a Windows specific one. Using the Cygwin port of e2fsck, you can ascertain that it's a valid filesystem (or repair it if it wasn't unounted cleanly) and then finally assign it a drive letter. Success!
Now, if I could just stop having dreams about filesystem internals - I've been looking at this for 2 weeks straight!