Hi Arvin,
how do you scan for /dev/hd0txy ?
If you use procmgr_event_notify(PROCMGR_EVENT_PATHSPACE) to wait for changes in pathname space
you may run into a race condition where you get the pulse before the device is realy available.
There's a PR54964 filed for this.
if this is the reason for your problem, you can work around it.
as you do a stat/open after receiving the pulse on the paths you want to check,
you have to check errno for EGAIN.
if this is set you're too fast, which means the pathname space is changed but the device is not yet ready, so you can 
delay some ms and try again.

HTH
/hp


 

>-----Ursprüngliche Nachricht-----
>Von: Arvin Baalu [mailto:community-noreply@qnx.com] 
>Gesendet: Dienstag, 24. Februar 2009 05:07
>An: general-filesystems
>Betreff: Auto mounting of file systems
>
>Hi
>What is the best way to automate mounting of external media 
>devices that are formatted in any number of file system 
>formats (FAT; FAT16; FAT32).  Since the device mountpoint that 
>gets created changes based on the file system type, we cannot 
>directly embed this in our startup script with the automount 
>option passed in to blk.
>
>We could create another resmgr that scans for the raw device 
>and then mount this accordingly based on the file system type 
>(/dev/hd0t11 is FAT32; /dev/hd0t6 is FAT; etc).  But we have 
>run into problems with this approach if we do rapid 
>insertion/removals.  Some one gets out of sync.
>
>Is there a easy way to accomplish this? 
>
>_______________________________________________
>General
>http://community.qnx.com/sf/go/post22783
>
> 
 
*******************************************
Harman Becker Automotive Systems GmbH
Management Board: Dr. Klaus Blickle (Chairman), Dr. Udo Hüls, Michael Mauser
Chairman of the Supervisory Board: Ansgar Rempp | Domicile: Karlsbad | 
Local Court Mannheim: Register No. 361395

 
*******************************************
Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen. Wenn Sie nicht der richtige Adressat 
sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und loeschen Sie diese Mail
. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have 
received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, 
disclosure or distribution of the contents in this e-mail is strictly forbidden.
*******************************************

Ok - right now the I am passing in the 'automount' option to the 'blk' device options:

e.g. blk cache=2m,automount=hd0t11:/fs

But as I indicated in my earlier post, the 'hd0t11' will change based on the file system format of the device that's 
inserted, so it's not a very clever approach.

I could follow your suggestion with the procmgr_event_notify, but I am trying to avoid inserting another application 
that does the mounting.  With rapid insertions & removals of the device, this external application invariably gets out 
of sync.  

Ideally we should have an option that we pass to 'blk' to support auto-mounting of any supported file system format 
without specifying hdNtXX.  

Hope my question is clear.

Thank you

> Hi
> What is the best way to automate mounting of external media devices that are 
> formatted in any number of file system formats (FAT; FAT16; FAT32).  Since the
>  device mountpoint that gets created changes based on the file system type, we
>  cannot directly embed this in our startup script with the automount option 
> passed in to blk.

You can use the syntax "blk automount=hd0@dos:/fs", which will mount any single DOS-type partition (1,4,6,11,12,14) from
 the specified device.

You can get progressively more complex with multiple automounts, multiple types, sharing the device, handling un-
partitioned raw media, etc.

> Is there a easy way to accomplish this? 

The static automount (which was originally just a workaround for the OS not supporting a mount call!) can be abused 
fairly heavily, and in a number of situations may be sufficient.

However the most flexible approach is the use of an external enumerator.  Something like MCD can be used here (I think 6
.4 does it this way for USB devices); this is a service/daemon that detects media insertions/ejections and can perform 
certain actions (including fs mounting) in response.