BUG: 16-bit setup.exe issues

[tschweikle at FIDUCIA.de]

stephen waters wrote:

> yes, that would have been my first thought except that it worked fine
> off of a WinNT 4.0 server whereas it did not work on samba in the exact
> same directory structure. on the samba box there is an error that says:
>
> "Cannot find file \\server\public\\temp\setup.dll. check to ensure the
> path and filename are correct and all libraries are available."
>
> notice the second set of \\ ?  that's where long_dir_name should have
> been. if i simply move the temp dir up one level to \\server\public\temp
> then it works b/c there are no longer any long dir names in the UNC
> path.
>
> i also notice that there's an error in the logfile, perhaps unrelated:
> [1999/09/20 12:47:32, 1] smbd/nttrans.c:call_nt_transact_ioctl(2387)
>   call_nt_transact_ioctl: currently not implemented
>
>
> -stephen
>
> Allen Reese wrote:
>>
>> Some versions of InstallShield, 5 IIRC, have problems launching setup off
>> of a UNC path.
>>
>> I was writing InstallShield installers for a while and ran into a bug
>> where some 16bit setup would fail off any UNC path because the
>> installshield code tries to get the drive letter of the UNC path and
>> fails.  I never had 8.3 related problems, but I ran into a lot of problems
>> if the drive I was trying to run the installers from was not mapped.  And
>> this was only with 16bit compatible installers.  If I did a 32bit only
>> installer, then it would install just fine via a UNC path, say
>> \\server\share\setup.exe  whereas, if I built the same installer but with
>> 16bit setuport, it wouldn't install from the UNC path under 95 unless I
>> mapped the drive.  ;)
>>
>> Check if the installer is an InstallShield installer, and if so that may
>> be part of the problem.  If you look in their KB any 16bit IS5 installers
>> have lots of UNC problems.  ;)
>>
>> But then all of this was 1-2 years ago.
>>
>> Allen Reese
>> Senior Software Engineer
>> Driversoft, Inc.
>> allen at driversoft.com
>>
>> On Tue, 21 Sep 1999, Stephen Waters wrote:
>>
>> > here's the scoop:
>> >
>> > samba 2.0.5a on linux 2.2.12+raidpatch.
>> >
>> > everything seems to work great except that 16-bit setup.exe files have
>> > trouble finding requisite .dlls in the current working directory if
>> > there are any non-8.3-compliant directories in the path.
>> >
>> > e.g.,
>> >
>> > 2 files, setup.exe setup.dll, in \\server\public\long_dir_name\temp\
>> > if execute setup.exe it will give an error saying that it cannot find
>> > setup.dll; however, if i move \\server\public\long_dir_name\temp\ to
>> > \\server\public\temp\ setup.exe finds setup.dll just fine.
>> >
>> > our Windows NT 4.0 server did not have any problems with this setup so i
>> > thought either 1) there is a bug in samba or 2) the client is stupid and
>> > NT has a workaround. i vote for [2], but i'd really like to see a
>> > workaround.
>> >
>> > i changed default case to upper when trying to figure out what was
>> > wrong.
>> >
>> >
>> > -stephen waters
>> > internal sysadmin
>> > amicus, inc.
>> >

There is a workaround for this sort of problem:

make dafault case lower/upper an set samba to ignore case (don't preserve
case on the server):

        preserve case = No
        short preserve case = No
        mangled names = No

The third option is a bit dangerous. But there are 16-bit programs arround
checking file names for 'illegal characters' thinking they would save
users time this way, not thinking about changes in future file systems
allowing these...

It should help.
BTW.: IBM-LAN-Server has the same problem. But there is no Workaround known.

--