Tried that - but all it showed me, for this mount (in fact - for any of them), was “/931share”.
In fact, as it turns out - this is an SMB share to a WIndows shared folder.
But I would never have been able to figure it out with the results returned with DF and mount.
Fortunately, since I had set up this mount last week - I figured it was either to the SMB share, or to a created folder on the same system (as I was testing).
I guess I was hoping for a result set something like:
/931share -----> dell000931\QNXBackups\
something very clear.
I can see this could be an issue for DOS devices also, as I may have one for the floppy, one for the USB flash drive, and one for a USB external HD.
Certainly moving forward documenting these in sysinit is one way to go - but as I was testing with this one (/931share), I didn’t document as well as I could have - therefore looking for information from the system itself.
I suspect (not really sure) that if you call open on /931share and then do an lstat() on it, there might be a hint.
Another thought is that the fd returned from open() is a QNX connection-id. Using this information it might be possible to figure out which resource manager is managing the device.
I have had share for other drives create directories at the share point in the past, later the mount replaces it, but generally it has happened when I’ve had something write to the share before it was mounted.
I don’t know exactly what you are trying to say here, but you brought up a point which I think should be mentioned.
With QNX 6 there is no contradiction in multiple resource managers sharing the same name space.
This can cause confusing results, but can also be very handy. Usually the priority is that whoever got there last is first in line.