Starting to make some progress.
Ian,
Keep in mind, mount ordering is LIFO - so last registered file system is
first called file system. RAW, for example, registers FIRST, and thus
gets called LAST.
If another FSD registers AFTER your FSD, then it will be called BEFORE
you to mount!
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ian Costello
Sent: Thursday, July 22, 2004 8:44 PM
To: ntfsd redirect
Subject: RE: [ntfsd] Mount issues with a filesystem…
Tony,
Thanks for the prompt reply. This is really interesting as we also had a
similar problem a while back with zip drives, that is we where handling
the mount request ourselves incorrectly and the zip drive was
inaccessible as a result. From your explanation this was the reason in
that case.
The problem I am looking at is also probably the same, I don’t have info
regarding whether the system has another (other than NTFS and FAST FAT)
filesystem installed but will get that shortly. If there is something
there that is installed before us, then will add the logic into the
registration of the filesystem that you discussed (maybe getting a
little ahead of myself)…
Anyway thanks for your help.
PS have been nagging my boss about a trip over to the states for one of
your filesystem seminars 
(he is also subscribed to this list so maybe
another hint will help)…
Thanks,
Ian Costello
>-----Original Message-----
>From: xxxxx@lists.osr.com
>[mailto:xxxxx@lists.osr.com]On Behalf Of Tony Mason
>Sent: Friday, 23 July 2004 10:17 AM
>To: Windows File Systems Devs Interest List
>Subject: RE: [ntfsd] Mount issues with a filesystem…
>
>
>I’m wondering if maybe a different FSD is trying to mount on top of
>your virtual volume BEFORE your FSD gets a chance to do so. I’ve had
>problems in this area before - the I/O Manager will treat certain
>errors as fatal and stop mount processing, so you never get called.
>
>For example, we had a file system that worked on WORM media. If NTFS
>were asked to mount a specific volume (on the WORM drive) it would
>return a STATUS_NONEXISTENT_SECTOR error (or some other clearly
>distinguished error, but that’s the best match I could find this
>evening in ntstatus.h) to the I/O Manager (because the sector it tried
>to read hadn’t been written yet) and our WORM media file system would
>not be called to mount (of course all we saw was that our mount was
>never called). It was volume specific because for a different volume
>it was fine - the region read by NTFS was valid and then NTFS failed
>the mount with a recoverable error (STATUS_UNRECOGNIZED_MEDIA most
>likely). We had to resolve this by adding logic to make sure that
>when a different file system registered, we would unregister and then
>re-register. While not generally applicable (can’t have two such file
>systems together) it solved the problem - and for the customer’s
>environment it was workable because it was controlled.
>
>Personally, I think the I/O Manager is far too conservative in this
>arena (it should allow other FSDs to try, even if there are "I/O
Errors"
>on the drive) but when I last inquired (many years ago) I was told by
>the powers-that-be that they saw no reason to change it.
>
>It would fit your description, but presumes that some other FSD is
>registering AFTER you register, and from the information provided, I
>can’t tell if that is the case or not.
>
>Regards,
>
>Tony
>
>Tony Mason
>Consulting Partner
>OSR Open Systems Resources, Inc.
>http://www.osr.com
>
>
>-----Original Message-----
>From: xxxxx@lists.osr.com
>[mailto:xxxxx@lists.osr.com] On Behalf Of Ian Costello
>Sent: Thursday, July 22, 2004 7:02 PM
>To: ntfsd redirect
>Subject: Re: [ntfsd] Mount issues with a filesystem…
>
>Tony,
>
>Whoops, I neglected to add that call in the pseudo code below. It is
>one of the last things that is done in DriverEntry(). Is there
>anything else that would cause this, i.e. as I create a “virtual disk”
>this may cause problems with the IoManager, particularly the way it is
>created? I don’t actually specify any device characteristics (although
>I thought that was not necessary).
>
>I know that we where getting IOCTL_DISK_CHECK_VERIFY ioctls for the
>virtual disk device, and incorrectly handling them (which I now do)
>via a STATUS_INVALID_PARAMTER return code. Ever since I discovered
>that, I added that handler and put the driver on a system in the field
>the problem went away, but I was not getting the
>IOCTL_DISK_CHECK_VERIFY ioctls??? This makes no sense to me and I
>don’t want to mark this as a fixed when I don’t understand what is
occurring…
>Thanks,
>
>- Ian Costello
>
>
>----- Original Message -----
>From: “Tony Mason”
>>To: “Windows File Systems Devs Interest List”
>>Sent: Friday, July 23, 2004 4:04 AM
>>Subject: RE: [ntfsd] Mount issues with a filesystem…
>>
>>
>>
>>>Where is your call to IoRegisterFileSystem? Without that, you won’t
>>
>>get
>>
>>>a mount call.
>>>
>>>Regards,
>>>
>>>Tony
>>>
>>>
>>>Tony Mason
>>>Consulting Partner
>>>OSR Open Systems Resources, Inc.
>>>http://www.osr.com
>>>
>>>
>>>-----Original Message-----
>>>From: xxxxx@lists.osr.com
>>>[mailto:xxxxx@lists.osr.com] On Behalf Of Ian Costello
>>>Sent: Thursday, July 22, 2004 10:06 AM
>>>To: ntfsd redirect
>>>Subject: [ntfsd] Mount issues with a filesystem…
>>>
>>>Hi All,
>>>
>>>I have gone through the archive looking for a similar problem but
>>
>>could
>>
>>>not find anything. So the problem I am having is with a File System
>>>driver (not a filter based driver), and Windows XP. Note: the
>>
>>filesystem
>>
>>>is currently functional (i.e. the filesystem is mounted without any
>>>issues) on the NT4, W2K, and to some extent on XP platforms.
>>>
>>>The problem is I am not getting the IRP_MN_MOUNT_VOLUME ioctl from
>>>the XP IOManager, and I don’t understand why? I used the OSR Device
>>>Tree application to determine if any of the devices that I have
>>>initialized during driver start up where invalid, but they looked
>
> fine.
>
>>>So a psuedo code rundown of driver startup is:
>>>
>>>DriverEntry()
>>>{
>>>generic initialization…
>>>
>>>IoCreateDevice(); /* creates the FILE_DEVICE_DISK_FILE_SYSTEM device
>>
>>/
>>
>>>IoCreateSymbolicLink(); / init the user visible name /
>>>
>>>more driver initialization
>>>which includes IoCreateDevice() / create a virtual FILE_DISK_DEVICE
>
>
>>>device */
>>>
>>>return Status;
>>>}
>>>
>>>Something I should mention (re: FILE_DISK_DEVICE above), although
>>>ashamedly, we also create a virtual disk device which we use to
>>>mount our filesystem(s) on.
>>>This is what I expect to get a mount request for, the Device Tree
>>
>>shows
>>
>>>these devices to be intialized correctly…
>>>
>>>Also I have not been able to reproduce this problem on any of my
>>>test systems locally, unfortunately this problem has, typically,
>>>only shown iteslf on customer sites (and not all of them) running XP
>
> Profesional.
>
>>>So it has been hard debugging this one, so I have been primarily
>>>inspecting the code (which is proprietry so I can’t give too much
>>
>>away,
>>
>>>if anything).
>>>
>>>Thanks,
>>>
>>>Ian Costello
>>>R&D Engineer SGI