fs-cifs with patch B

I just installed patch 6.0B and I now have problems with fs-cifs. Previously I had mounted a directory using the command

fs-cifs -a //centauri:192.168.145.40:/QNX_files /fs/centauri dummy dummy

ls /fs

cd0 centauri hd0-dos

The server is Windows98 and the QNX_files directory is marked as shared and without password protection. This had worked before I installed patch B. Now as soon as I attempt to copy a file to the remote directory, the connection is lost.

cp config /fs/centauri/tmp

cp: Can’t open destination file. (/fs/centauri/tmp//config): No such file or directory

ls /fs

cd0 hd0-dos

I tried to add the verbose option to see what is going on. The only suspect message is the “Bad fiel descriptor” when first attempting to mount QNX_files, but the second attempt appears to work. I can list the directory of /fs/centauri after mounting with fs-cifs, but as soon as I attempt to write, the connection is broken.

fs-cifs -av //centauri:192.168.145.40:/QNX_files /fs/centauri dummy dummy

fs-cifs: starting…
fs-cifs: mount: 192.168.145.40:/QNX_files → /fs/centauri by dummy [0]
fs-cifs: new server
fs-cifs: establishing connection to 192.168.145.40:centauri
fs-cifs: smb connection successful
fs-cifs: logging dummy on 192.168.145.40
fs-cifs: logon successful. uid [0] maps to [0]
fs-cifs: mounting 192.168.145.40:/QNX_files
fs-cifs: smb_mount: Bad file descriptor
fs-cifs: mounting 192.168.145.40:/QNX_FILES

Is this a new bug with patch B? How do I fix this?

Thanks,
Rob Dyck

It’s a bug in patch B. Easiest way is to get /usr/sbin/fs-cifs of patch A
and use this file.
Or deactive patch B
Markus

“Robert Dyck” <rbdyck@astra.mb.ca> wrote in message
news:Voyager.010515170606.647203A@rbdyck…

I just installed patch 6.0B and I now have problems with fs-cifs.
Previously I had mounted a directory using the command

fs-cifs -a //centauri:192.168.145.40:/QNX_files /fs/centauri dummy dummy

ls /fs

cd0 centauri hd0-dos

The server is Windows98 and the QNX_files directory is marked as shared
and without password protection. This had worked before I installed patch B.

Now as soon as I attempt to copy a file to the remote directory, the
connection is lost.

cp config /fs/centauri/tmp

cp: Can’t open destination file. (/fs/centauri/tmp//config): No such file
or directory

ls /fs

cd0 hd0-dos

I tried to add the verbose option to see what is going on. The only
suspect message is the “Bad fiel descriptor” when first attempting to mount

QNX_files, but the second attempt appears to work. I can list the directory
of /fs/centauri after mounting with fs-cifs, but as soon as I attempt to
write, the connection is broken.

fs-cifs -av //centauri:192.168.145.40:/QNX_files /fs/centauri dummy

dummy
fs-cifs: starting…
fs-cifs: mount: 192.168.145.40:/QNX_files → /fs/centauri by dummy [0]
fs-cifs: new server
fs-cifs: establishing connection to 192.168.145.40:centauri
fs-cifs: smb connection successful
fs-cifs: logging dummy on 192.168.145.40
fs-cifs: logon successful. uid [0] maps to [0]
fs-cifs: mounting 192.168.145.40:/QNX_files
fs-cifs: smb_mount: Bad file descriptor
fs-cifs: mounting 192.168.145.40:/QNX_FILES

Is this a new bug with patch B? How do I fix this?

Thanks,
Rob Dyck

Just curious. Isn’t the purpose of these repositories so that you can pick
and choose which versions of what software from which repositories you
actually want to run. Why can’t we just disable the patch B of fs-cifs?


Bill Caroselli - Sattel Global Networks
1-818-709-6201 ext 122



“Markus Loffler” <loffler@ces.clemson.edu> wrote in message
news:9drra0$t1s$1@inn.qnx.com

It’s a bug in patch B. Easiest way is to get /usr/sbin/fs-cifs of patch A
and use this file.
Or deactive patch B
Markus

Well, then the repository must be structured in showing all the components
(e.g., fs-cifs) separately - if you consider the whole operating system,
this would blow up pretty much. Plus, then you would need to think what
component of patch A would still work together with another component of
patch B and what not. That’s why the whole update is only split in a couple
of components (I think, for example, you are able to disable patch B only
for C++ development separately if I remember)
Markus


“Bill Caroselli” <Bill@Sattel.com> wrote in message
news:9ds3nr$4ua$1@inn.qnx.com

Just curious. Isn’t the purpose of these repositories so that you can
pick
and choose which versions of what software from which repositories you
actually want to run. Why can’t we just disable the patch B of fs-cifs?


Bill Caroselli - Sattel Global Networks
1-818-709-6201 ext 122



“Markus Loffler” <> loffler@ces.clemson.edu> > wrote in message
news:9drra0$t1s$> 1@inn.qnx.com> …
It’s a bug in patch B. Easiest way is to get /usr/sbin/fs-cifs of patch
A
and use this file.
Or deactive patch B
Markus

Exactly.

I would think that when patch B came out, every module, and only every
module that was different in patch B from patch A, etc., would be listed as
a seperate entity, along with whatever prerequisits it may have.

I don’t know about anyone else, but so far these repositories are a big pain
in the ass compared to just downloading an archiving and picking the modules
that you wish to install. Or if you need to back track, picking the modules
from the previous archive that you wnt to replace the newer versions. As I
said, I thought that the reason for repositories was to make life easier.
So far, I don’t feel like they’ve done me any favors. (And we won’t talk
about all of the times I though a file was in one place when it was realy
somewhere else.)

Am I missing something?


Bill Caroselli - Sattel Global Networks
1-818-709-6201 ext 122



“Markus Loffler” <loffler@ces.clemson.edu> wrote in message
news:9dsq4u$heg$1@inn.qnx.com

Well, then the repository must be structured in showing all the components
(e.g., fs-cifs) separately - if you consider the whole operating system,
this would blow up pretty much. Plus, then you would need to think what
component of patch A would still work together with another component of
patch B and what not. That’s why the whole update is only split in a
couple
of components (I think, for example, you are able to disable patch B only
for C++ development separately if I remember)
Markus


“Bill Caroselli” <> Bill@Sattel.com> > wrote in message
news:9ds3nr$4ua$> 1@inn.qnx.com> …
Just curious. Isn’t the purpose of these repositories so that you can
pick
and choose which versions of what software from which repositories you
actually want to run. Why can’t we just disable the patch B of fs-cifs?


Bill Caroselli - Sattel Global Networks
1-818-709-6201 ext 122



“Markus Loffler” <> loffler@ces.clemson.edu> > wrote in message
news:9drra0$t1s$> 1@inn.qnx.com> …
It’s a bug in patch B. Easiest way is to get /usr/sbin/fs-cifs of
patch
A
and use this file.
Or deactive patch B
Markus

\

Well, how many modules do you then want to have? If fs-cifs is separate,
then you’ll make all filesystems separate and at some point you end up
making each file separate…
I guess it’s much more work, especially with listing prerequisits as you
mention.
Also, then you run into hundreds of people that installed a certain
combination of files and everybody first needs to post the combination of
files installed before asking for help in case of a problem.
I see your point, but as far as I’m concerned, it’s ok fixing just one file
or two like fs-cifs.
Markus


“Bill Caroselli” <Bill@Sattel.com> wrote in message
news:9dssph$j1r$1@inn.qnx.com

Exactly.

I would think that when patch B came out, every module, and only every
module that was different in patch B from patch A, etc., would be listed
as
a seperate entity, along with whatever prerequisits it may have.

I don’t know about anyone else, but so far these repositories are a big
pain
in the ass compared to just downloading an archiving and picking the
modules
that you wish to install. Or if you need to back track, picking the
modules
from the previous archive that you wnt to replace the newer versions. As
I
said, I thought that the reason for repositories was to make life easier.
So far, I don’t feel like they’ve done me any favors. (And we won’t talk
about all of the times I though a file was in one place when it was realy
somewhere else.)

Am I missing something?


Bill Caroselli - Sattel Global Networks
1-818-709-6201 ext 122



“Markus Loffler” <> loffler@ces.clemson.edu> > wrote in message
news:9dsq4u$heg$> 1@inn.qnx.com> …
Well, then the repository must be structured in showing all the
components
(e.g., fs-cifs) separately - if you consider the whole operating system,
this would blow up pretty much. Plus, then you would need to think what
component of patch A would still work together with another component of
patch B and what not. That’s why the whole update is only split in a
couple
of components (I think, for example, you are able to disable patch B
only
for C++ development separately if I remember)
Markus


“Bill Caroselli” <> Bill@Sattel.com> > wrote in message
news:9ds3nr$4ua$> 1@inn.qnx.com> …
Just curious. Isn’t the purpose of these repositories so that you can
pick
and choose which versions of what software from which repositories you
actually want to run. Why can’t we just disable the patch B of
fs-cifs?


Bill Caroselli - Sattel Global Networks
1-818-709-6201 ext 122



“Markus Loffler” <> loffler@ces.clemson.edu> > wrote in message
news:9drra0$t1s$> 1@inn.qnx.com> …
It’s a bug in patch B. Easiest way is to get /usr/sbin/fs-cifs of
patch
A
and use this file.
Or deactive patch B
Markus



\