Bug 4384 - Non-Wildcard copy fails on DOS with file not found
Summary: Non-Wildcard copy fails on DOS with file not found
Status: RESOLVED FIXED
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: File Services (show other bugs)
Version: 3.0.23d
Hardware: Other Other
: P3 normal
Target Milestone: none
Assignee: Samba Bugzilla Account
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-02-09 08:54 UTC by Michael Apel
Modified: 2007-03-12 12:12 UTC (History)
2 users (show)

See Also:


Attachments
debug 10 log (12.82 KB, text/plain)
2007-02-09 08:55 UTC, Michael Apel
no flags Details
packet trace (different file but same result) (16.19 KB, text/plain)
2007-02-09 08:55 UTC, Michael Apel
no flags Details
binary packet trace (753 bytes, application/octet-stream)
2007-02-12 02:21 UTC, Michael Apel
no flags Details
Patch for 3.0.23d/3.0.24 (899 bytes, patch)
2007-03-08 20:09 UTC, Jeremy Allison
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Apel 2007-02-09 08:54:48 UTC
Since upgrading to 3.0.23d from 3.0.13a (Debian Sarge) we're having problems with our DOS clients.

Copying a specific file from the server (copy x:\test.txt c:\test.txt) fails with "file not found" although the file is perfectly readable, e.g you can view them with edit. A few files work strangely enough although they posses the exact same owner and permissions.

Copying works flawlessly when using wildcard copy (copy x:\test.tx? c:\test.txt), just replace one single character with a ?.

Looking at the logs left me clueless and confused. It only sounds like it could be related to bug 3858 although hide unreadable doesn't make a difference.

I'll attach a debug 10 log and a clear-text packet trace.
Comment 1 Michael Apel 2007-02-09 08:55:29 UTC
Created attachment 2281 [details]
debug 10 log
Comment 2 Michael Apel 2007-02-09 08:55:58 UTC
Created attachment 2282 [details]
packet trace (different file but same result)
Comment 3 Jeremy Allison 2007-02-11 20:32:57 UTC
Please don't post an ASCII packet trace, that's useless I'm afraid. What I need is the binary packet trace (ie. the raw ethernet data that ethereal captured).
Thanks,
Jeremy.
Comment 4 Michael Apel 2007-02-12 02:21:59 UTC
Created attachment 2287 [details]
binary packet trace
Comment 5 Jeremy Allison 2007-03-08 20:03:36 UTC
Ok, this is the problem as seen in the log :

 stat_cache_lookup: lookup succeeded for name [INSTALL/NETZ.BAT] -> [INSTALL/netz.bat]
[2007/02/09 12:03:04, 5] smbd/dir.c:dptr_create(392)
  dptr_create dir=INSTALL
[2007/02/09 12:03:04, 3] smbd/dir.c:dptr_create(512)
  creating new dirptr 6 for path INSTALL, expect_close = 0
[2007/02/09 12:03:04, 4] smbd/reply.c:reply_search(1186)
  dptr_num is 6
[2007/02/09 12:03:04, 8] smbd/reply.c:reply_search(1204)
  dirpath=<INSTALL> dontdescend=<>
[2007/02/09 12:03:04, 10] smbd/dir.c:user_can_read_file(864)
  user_can_read_file: SMB_VFS_STAT failed for file INSTALL/NETZ.BAT with error Datei oder Verzeichnis nicht gefunden
[2007/02/09 12:03:04, 10] smbd/dir.c:is_visible_file(1015)
  is_visible_file: file INSTALL/NETZ.BAT is unreadable.

Ths interesting thing is that the stat cache lookup shows the path "INSTALL/netz.bat", which the previous open shows as valid, but the stat call is trying "INSTALL/NETZ.BAT" which I'm guessing doesn't exist.

I think I see the bug....
Comment 6 Jeremy Allison 2007-03-08 20:09:26 UTC
Created attachment 2318 [details]
Patch for 3.0.23d/3.0.24

This should fix it ! Please let me know.
Jeremy.
Comment 7 Michael Apel 2007-03-12 12:01:15 UTC
The patched 3.0.24 seems to work fine after a quick test. Great work!

Any chance of this still going in the official 3.0.25 branch or are you already too late in the game for that (just saw the pre1 announcement)? I don't have a good feeling about running a self-built samba in a production environment.
Comment 8 Jeremy Allison 2007-03-12 12:12:11 UTC
This will *definately* be in the 3.0.25 - we're not quite at feature
freeze yet so there's easily enough time.
I'm closing this one out - thanks a lot for your help.
Jeremy.