mapping drives in NTO

I used a call to system(“fs-cifs …”) in a NTO2 C program to map a
drive. I need to be able to unmap this drive when the program exits.
Right now, the only way I have of doing this is to manually look for
the pid of the fs-cifs server and “kill” it. Either I need a command
to close the server or a way to find the pid of the server so I can
make a call to system("kill ") within my code. Any help would be
great considering I have posted 3 previous times for other problems and
NEVER gotten any help. THanks.


Sent via Deja.com http://www.deja.com/
Before you buy.

clarkni@my-deja.com wrote:

I used a call to system(“fs-cifs …”) in a NTO2 C program to map a
drive. I need to be able to unmap this drive when the program exits.
Right now, the only way I have of doing this is to manually look for
the pid of the fs-cifs server and “kill” it. Either I need a command
to close the server or a way to find the pid of the server so I can
make a call to system("kill ") within my code. Any help would be
great considering I have posted 3 previous times for other problems and
NEVER gotten any help. THanks.

you could fork() and then execl() into fs-cifs – the parent remembering
the child pid to kill later (or use spawn())

if you have slay utility (don’t know if this shipped with the version you have)
and only running 1 fs-cifs, you could system(“slay -f fs-cifs”)

note: later versions should support umount

clarkni@my-deja.com wrote:

I used a call to system(“fs-cifs …”) in a NTO2 C program to map a
drive. I need to be able to unmap this drive when the program exits.
Right now, the only way I have of doing this is to manually look for
the pid of the fs-cifs server and “kill” it. Either I need a command
to close the server or a way to find the pid of the server so I can
make a call to system("kill ") within my code. Any help would be
great considering I have posted 3 previous times for other problems and
NEVER gotten any help. THanks.

Sent via Deja.com > http://www.deja.com/
Before you buy.

I don’t think QSSL officially answers postings on comp.os.qnx. You
might want to point your newsreader at inn.qnx.com and post on the
appropriate newsgroup of the QNX Developer’s Network (I think that’s the
official name of it).

Dean Douthat <ddouthat@faac.com> wrote:

I don’t think QSSL officially answers postings on comp.os.qnx. You
might want to point your newsreader at inn.qnx.com and post on the
appropriate newsgroup of the QNX Developer’s Network (I think that’s the
official name of it).

Dean is correct. Public newsgroups such as comp.os.qnx are not supposed
to be used for commercial purposes, and providing tech support could be
considered such a use.

Public newsgroup posts are propagated through and stored on a lot of
computers, so a large increase in the number of comp.os.qnx posts
would use a lot of bandwidth and storage space that might affect your
average internet user who just wants to look at dirty pictures.

Public newsgroup posts are propagated through and stored on a lot of
computers, so a large increase in the number of comp.os.qnx posts
would use a lot of bandwidth and storage space that might affect your
average internet user who just wants to look at dirty pictures.

And we don’t want to limit the bandwith for that purpose… :wink: