Ok, I think I've got something regarding the 2.4.18 oopses. (oopsen?)
There are two errors in the changes to smbfs in 2.4.18-rc3 (and 2.5.5)
1. SMB_MAXNAMELEN (max length of a single path component) was used where
SMB_MAXPATHLEN (max total path length) should have been used.
2. The charset conversion routine was modified to return errors as
negative values but not all callers was changed to handle this. When an
"illegal" character was hit the length of the string was set to
0xffffffff and when computing the hash value it read outside the kernel
memory.
Attached is a patch vs 2.4.18 that fixes these issues for me. Please test
and let me know.
If I select a codepage/charset combination that doesn't match I now get a
somewhat cryptic message instead of an oops (just a temporary thing).
"smbfs: filename charset conversion failed"
The file is then hidden, which is bad. Conversion errors should map to '?'
as they used to or do some translation into ":####" strings. I'll do
something about that.
Some comments on what some of you have been doing:
The smbfs remote codepage can never be utf8 since there are no smb servers
that talk utf8. It can be one of the dos codepages, it can be blank or
with additional patches it can be a 2 byte little endian unicode format.
Furthermore, the local charset must be one that matches the chars used in
the remote set. Otherwise you get conversion errors. A few known good
combinations are:
cp850 <-> iso8859-1
cp866 <-> koi8-r
cp932 <-> euc-jp
(the right is the local = linux side)
See also the smb.conf manpage.
But even with these it seems to be possible to create chars that do not
match, and I think it is caused by windows trying to map unicode to a
codepage and not finding a matching char to use.
Local utf8 always matches the remote and is preferred if your system is
setup to handle it.
I would explain the reported
smb_proc_readdir_long: name=<directory> result=-2, rcls=1, err=2
as a name conversion problem. If the conversion failed one way it used to
be truncated and would then fail when sent back to the server. The error
is ERRDOS - ERRbadfile (File not found).
Check the config and the nls maps used.
/Urban
This archive was generated by hypermail 2b29 : Thu Mar 07 2002 - 21:00:21 EST