Bug 51 - Excel can't find a non-writeable .xls if parent's name not ASCII
Excel can't find a non-writeable .xls if parent's name not ASCII
Status: CLOSED FIXED
Product: Samba 2.2
Classification: Unclassified
Component: File Services
2.2.8a
All Linux
: P3 normal
: ---
Assigned To: Jeremy Allison
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2003-04-30 01:02 UTC by Dragan Krnic
Modified: 2005-11-14 09:29 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dragan Krnic 2003-04-30 01:02:16 UTC
Short description of likely problem:

      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 to the file.

      However smbd/open_file.c misrepresents the error as
   "No such file or directory" if the parent directory
   name contains non-ASCIIs?

Long-winding description:

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?
Comment 1 Dragan Krnic 2003-04-30 01:05:22 UTC
This is my first bug report. If you need more info,
logs etc. please drop a line.
Comment 2 Gerald (Jerry) Carter 2003-04-30 06:45:24 UTC
Jeremy,

Can you take a look at this one?  I've lowered the priority 
to a P3 since it looks like an extended character defect.

Comment 3 Dragan Krnic 2003-05-01 10:25:21 UTC
In my understanding the problem is that after calling fd_open the open_file
then calls inherit_access_acl which never leaves any traces in debug logs but
conceivably itself causes other errors ("No such file or directory" for 
instance), which mask the original error condition in errno ("Permission
denied"). I haven't looked into it but to me it obviously makes no sense to 
call it before checking up if fd_open was at all successful. So the resolution 
of the bug would be to change the following sequence in smbd/open.c

171   fsp->fd = fd_open(conn, fname, local_flags, mode);
172   (void) inherit_access_acl(conn, fname, mode); /* DOESN'T BELONG HERE */
173                                                 /**xxxxxxxxxxxxxxxxxxx**/
174   if (fsp->fd == -1)  {
175      DEBUG(3,("Error opening file %s (%s) (local_flags=%d) (flags=%d)\n",
176               fname,strerror(errno),local_flags,flags));
177      check_for_pipe(fname);
178      return False;
179   }

to this

171   fsp->fd = fd_open(conn, fname, local_flags, mode);
172 
173   if (fsp->fd == -1)  {
174      DEBUG(3,("Error opening file %s (%s) (local_flags=%d) (flags=%d)\n",
175               fname,strerror(errno),local_flags,flags));
176      check_for_pipe(fname);
177      return False;
178   }                                             /**vvvvvvvvvvvvvvvvvvvvv**/
179   (void) inherit_access_acl(conn, fname, mode); /* MAKES MORE SENSE HERE */
                                                    /**^^^^^^^^^^^^^^^^^^^^^**/

I thank you very much for teaching me to fish instead of waitinig to get the
fish from you. There is obviously much more that people can do themselves.
Especially if they feel that lowering of priority was unjust and makes you
think what your priorities are.

As it is Samba is sailing against strong winds here too. There is nothing more 
annoying for suits, who eventually decide on the deployment, when they can't 
open "büdget/Kasse.xls" because US/GB/AU developers don't hold extended
character defects for high enough of a priority. It makes me feeil that it's 
because I is a Crout.

Cheers
Dragan
Comment 4 Jeremy Allison 2003-05-01 10:47:39 UTC
The proposed fix looks correct. However the bug is really against 3.0, not 2.2.8a.
I have checked in the fix.
Jeremy.
Comment 5 Gerald (Jerry) Carter 2003-05-20 08:22:28 UTC
done
Comment 6 Gerald (Jerry) Carter 2005-11-14 09:29:39 UTC
database cleanup