[Samba] Excel can't find a non-writeable .xls if parent's name not ASCII

Dragan Krnic dkrnic at lycos.com
Tue Apr 29 22:02:47 GMT 2003


A path like this:

   \\samba\ä\a.xls

cannot be found by Excel unless the user (or
his group) has the write privilege on the file.
(The funny looking directory name is a German
"a" with a lazy colon on top of it, ASCII code
0xe4.)

A symbolic link "ae->ä" solves the problem:

   \\samba\ae\a.xls

pointing to the same file through an ASCII
symbolic link is OK but unpracticable. The 
problem doesn't show up if the user (or his
group) has write-access to the file.

It looked like the problem was in the following
global parameter of my samba 2.2.8a:

   character set = ISO8859-1

If it is set as shown the paths with special German
characters appear as expected both on an SMB
client and on the Linux box (SuSE 8.1 with
kernel 2.4.20-4GB) but then we have the said problem
with Excel (and no other Application, AFAIK). 
Curiously the samba's own logs never display such
names correctly, no matter what the setting.

If I comment it out the paths with non-ASCII
chars which were created while the parameter
was in force suddenly appear quite different
on an SMB client (Win2K):

  29.04.2003  21:13       <DIR>          A&#9472;
  29.04.2003  21:13       <DIR>          OÍ
  29.04.2003  21:13       <DIR>          U&#9604;
  29.04.2003  21:13       <DIR>          õa
  29.04.2003  21:13       <DIR>          ÷o
  29.04.2003  21:14       <DIR>          &#9600;s
  29.04.2003  21:13       <DIR>          ³u

(To help identify the characters I used the
nearest ASCII big char before the uppercase
version and the nearest ASCII small char after
the lowercase version of such characters).

New files created after commenting the parm out
retain their expected appearance on the client
but look strange on Linux:

 drwxrwxrwx    2 root     root 96 Apr 29 21:58 A?
 drwxrwxrwx    2 root     root 96 Apr 29 21:58 O?
 drwxrwxrwx    2 root     root 96 Apr 29 21:58 U?
 drwxrwxrwx    2 root     root 96 Apr 29 21:58 ?a
 drwxrwxrwx    2 root     root 96 Apr 29 21:58 ?o
 drwxrwxrwx    2 root     root 96 Apr 29 21:58 ás
 drwxrwxrwx    2 root     root 96 Apr 29 21:58 ?u

In either case the problem does not arise so long
as "character set" is commented out.

Toggling the parameter back in to smb.conf
makes unusable those paths with non-ASCII
characters which were created while the parameter
was commented out.

I've watched what happens when Excel tries to open
a non-writeable spreadsheet file in one of those 
directories with non-ASCII characters in their
names while the parameter "character set" is set
so that these non-ASCII characters appear as
expected on both sides of the Samba server.

The "filemon.exe" shows that after a convoluted
quiz session between the Win2K client and Samba
server the Excel program gets a "FILE NOT FOUND" 
result after an "IRP_MJ_CREATE" request on the
subject file. However, before this error occurs
the same request for this file was issued 6 more
times by Excel and another 6 times by the Explorer,
always returning "SUCCESS" as the result.

Samba log at level 3 comes to the same conclusion:

  smbd/open.c:open_file(177) Error opening file
    A~N/a.xls (No such file or directory) 
    (local_flags=2) (flags=2)
  smbd/error.c:error_packet(94) error string =
    No such file or directory
  smbd/error.c:error_packet(113) error packet at 
    smbd/nttrans.c(889) cmd=162 (SMBntcreateX) 
    NT_STATUS_OBJECT_NAME_NOT_FOUND

At level 4 it is preceded by this diagnostic:

  smbd/open.c:open_file_shared1(974) calling open_file 
    with flags=0x2 flags2=0x0 mode=0766

At level 5 we see that it was part of an
SMBntcreateX transaction but still no explanation
why it should conclude that there is "No such file
or directory" for a perfectly existent file. I lost
patience here and set the debug level to 999. It looks
like it is a bug in Samba because what really happens
is that "fd_open" tries to open the file with O_RDWR
(with flags=0x2) and gets the error "Permission 
denied" because the user doesn't have the write 
permission for the file.

Why does it then reply with "No such file ..."
only if the parent directory name contains non-ASCIIs?

Mind boggles.

Does someone have a fix for this ?
Or can produce it without introducing another prob ?
John? Jeremy? Tridge?

Cheers
Dragan


____________________________________________________________
Get advanced SPAM filtering on Webmail or POP Mail ... Get Lycos Mail!
http://login.mail.lycos.com/r/referral?aid=27005


More information about the samba mailing list