BUG: 16-bit setup.exe issues

Stephen Waters swaters at amicus.com
Mon Sep 20 19:22:37 GMT 1999



tschweikle at FIDUCIA.de wrote:
> 
> 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
> 

out of curiousity, is this how NT handles this sort of thing?

-stephen


More information about the samba-ntdom mailing list