samba - Dec 1997 - "Save As" fails to Samba drive, works on Win95, NT, Novell ...

Hi --

I originally posted the following message about 2 weeks ago -- I don't mean
to
annoy but really need to solve this problem - if anyone can shed any light on 
the issue I'd greatly appreciate it.

Since the original post, we've run the application with its data on network 
drives shared from 95, NT, and Novell, and all work fine, as does saving 
locally.  It only fails on a Samba server.

Thanks,
Joshua

-------------- repost
From: Joshua Heling <jrh@securepipe.com>
To: Multiple recipients of list <samba@samba.anu.edu.au>
Subject: problems with "Save As" in BNA Income Tax Planner for Windows
Date: Thu, 4 Dec 1997 10:00:22 +1100


Hi -

A client reported this morning that the "Save As" function in some tax
planning software they use "didn't work with the new server"
(Samba 1.9.17p2
on intel/linux v 2.0.30).  All client machines are Win95 OSR2.

Essentially, when you type a name in the save as dialog and press enter, a 
backslash is added to the end of the new filename (in the dialog, that is), 
there is a brief pause, and the name is replaced by the standard windows 
dialog box extension filter, which in this case is '*.it*'.  There is no
error
message, the user is still looking at the save as dialog box, and no new file 
is created.

This behavior was observed on any networked samba drives at the client's 
office, and I have repeated it (many times) in my office on both 1.9.17p2 and 
1.9.18alpha12.  Doing a "save as" to a local drive works without any
problem.

I've gathered logs at debug levels 3, 4, and 5.  I am not able to get any 
useful information from them myself, but I did find the few lines logged right 
before the error occurred to be interesting ("NEWFILE.IT" is the file
I'm
creating):

- - - start log snippet - - - 
12/03/97 16:29:46 Transaction 1201 of length 41
switch message SMBfindclose (pid 14533)
reply_findclose, cnum = 87, dptr_num = 14
12/03/97 16:29:46 SMBfindclose cnum=87, dptr_num = 14
12/03/97 16:29:46 Transaction 1202 of length 100
switch message SMBtrans2 (pid 14533)
call_trans2findfirst: dirtype = 0, maxentries = 6, close_after_first=0, 
close_if
_end = 0 requires_resume_key = 0 level = 260, max_data_bytes = 2432
unix_clean_name [./NEWFILE.IT/*.IT*]
unix_clean_name [NEWFILE.IT/*.IT*]
unix_clean_name [NEWFILE.IT]
12/03/97 16:29:46 error packet at line 644 cmd=50 (SMBtrans2) eclass=1 ecode=3
error string = No such file or directory
chdir to /var/log
- - - end log - - -

"No such file or directory" ??? Well, no, there shouldn't be one,
as I'm
trying to save as a new file!  This is with fairly standard configuration 
settings, significant globals are 'short preserve case' and
'preserve case'
both yes, 'locking' and 'share modes' both yes.  Service params
are:

   browseable = yes
   writeable = yes
   public = no
   ;; everything is done by the users group -- allows sharing
   force group = users
   force create mode = 0664
   force directory mode = 0775

Thinking that perhaps the problem was related to name mangling, I tried adding 
the following mangling-related parameters, but to no avail:

	mangle case = no
	case sensitive = no
	default case = upper
	preserve case = no
	short preserve case = no

I also tried setting "strict locking" and even "fake
oplocks", but neither
worked.  While I haven't yet tried 1.9.18alpha12 on a raised debug level, it
does appear to have the same problem.

Can anyone shed some light on this problem?  I haven't included the debug
logs
for the sake of space, but will happily send them to anyone who wants more 
info.  This is a rather severe issue for the client, and is unfortunately 
coming immediately after their conversion from Novell (in which the app worked 
fine.. :( )

----------- end repost --------

--------
Joshua Heling				             jrh@securepipe.com
SecurePipe Communications, Inc.

> Essentially, when you type a name in the save as dialog and press enter, a 
> backslash is added to the end of the new filename (in the dialog, that is),
> there is a brief pause, and the name is replaced by the standard windows 
> dialog box extension filter, which in this case is '*.it*'.  There
is no error
> message, the user is still looking at the save as dialog box, and no new
file
> is created.
Is it an app written in Visual Basic ? Such apps seem to do
strange things with filenames passed to 'open'.

Can you download 1.9.18alpha13 and send me a debug
level 10 log of the app running it ?

Thanks,

	Jeremy Allison,
	Samba Team.



-- 
--------------------------------------------------------
Buying an operating system without source is like buying
a self-assembly Space Shuttle with no instructions.
--------------------------------------------------------