SAMBA_2_2: Failure with smbmounted volume

[Urban Widmark]

On Thu, 6 Dec 2001, Esh, Andrew wrote:

> My use of the word "smbmount" may have caused some confusion. My problem is
> not with that tool, but with the volumes mounted as type "smbfs".

There is no confusion on my part, I understood just fine what you are
doing.

> The problem appears to be that the smbfs code returns "EIO" when a file is
> not found, which is wrong. It should return "ENOENT", which is right. This
> is what is returned by the old code. When "cvs" sees "EIO", it errors out,
> because it was expecting success, or "ENOENT". It does not expect "EIO".

You are refering to "the old code" as if you have changed the code that is
involved with handling the open() syscall on a smbfs mount, but you
haven't.

smbmount is not involved in handling the open request, it doesn't return
anything. The only thing it does is reconnect if smbfs wants it to. smbfs
wants it to reconnect when smbfs thinks it has a network problem.

smbfs also returns EIO to userspace when it gets a network problem and
smbmount could not reconnect. When smbfs does this it always prints
something to the kernel logs.

That is why I was asking you if you see any kernel messages.


A possible explanation for why the smbfs code works with one version of
smbmount and not the other is that the new smbmount fails for some reason
when asked to reconnect.

The reason you see EIO on open is not that smbfs returns EIO when a file
does not exist, it is returned because it can't check with the server if
the file exists. Huge difference.


The only change in smbmount code is that someone removed the smbmount
implementation of xstrdup. That is why I thought the difference could be
in what smbmount negotiates (where smbmount uses libsmb code).

/Urban