Samba services to NT client (PR#8411)

[Jeremy Allison]

james.strauch at beasys.com wrote :

> The problem is with the share "beasw". (see config below) This share
> contains executable installs for various standard PC desktop software. The
> share works fine and is viewable and writable by both Windows95 clients and
> Windows-NT 4.0 clients. But when trying to install the applications (such
> as Meeting Maker, 2nd Copy 97, Netscape, etc.) from the share onto
> Windows-NT 4.0 clients the following pop-up error message is displayed:
>
> Cannot find \\san-diego\beasw\2ndcopy97\setup97.exe. Windows needs this
> file to run \\san-diego\beasw\2ndcopy97\setup.exe.
>
> This only happens from the NT clients. It installs fine onto a Windows95
> client. And this happens with any of the setup or install executables on
> this share. Has anyone ever run into this problem?


Running 16 bit programs from Windows NT on a Samba mapped drive
---------------------------------------------------------------

The Windows NT redirector has a bug when running against a 
Samba or Windows 95 mapped drive and attempting to run a
16 bit executable.

The problem occurs when the pathname to a 16 bit executable
contains a non 8.3 filename complient directory component,
Windows NT will fail to load the program and complain it
cannot find the path to the program.

It can be verified that this is a bug in Windows NT and
not Samba as the same problem can be reproduced exactly
when attempting to run the same program with the same
pathname from a Windows 95 server (ie. the problem still
exists even with no Samba server involved).

Microsoft have been made aware of this problem, it is
unknown if they regard it as serious enough to provide
a fix for this.

One of the reasons this problem is reported frequently
is that InstallShield setup.exe executables are frequently
written as 16 bit programs, and so hit this problem.

As a workaround, you may create (on a Samba server at
least) a symbolic link with an 8.3 complient name to 
the non 8.3 complient directory name, and then the 16
bit program will run. Alternatively, use the 8.3
complient mangled name to specify the path to run
the binary.

This will be fixed when Samba adds the NT-specific
SMB calls (currently targeted for the next major
Samba release), as once the NT SMB calls are used
this problem no longer occurs (which is why the
problem doesn't occur when running against a drive
mapped to a Windows NT server).

Regards,

	Jeremy Allison.
	Samba Team.