cifs backport is current

Steve French smfrench at
Mon Jul 16 04:22:01 GMT 2007

NTCreateX kills current Samba 3 (Version 3.0.27pre1-SVN-build-23773
from svn) smbd see below.   I reextracted a clean tree from SAMBA_3_0
svn and rebuilt to make sure.

[2007/07/15 23:14:24, 0] lib/fault.c:fault_report(45)
[2007/07/15 23:14:24, 0] lib/util.c:smb_panic(1656)
  PANIC (pid 13655): internal error
[2007/07/15 23:14:24, 0] lib/util.c:log_stack_trace(1760)
  BACKTRACE: 11 stack frames:
   #0 bin/smbd(log_stack_trace+0x2d) [0x80254af4]
   #1 bin/smbd(smb_panic+0x78) [0x80254c22]
   #2 bin/smbd [0x80240723]
   #3 [0xffffe420]
   #4 bin/smbd(talloc_free+0xa9) [0x8023981a]
   #5 bin/smbd(reply_ntcreate_and_X+0xece) [0x80091f9c]
   #6 bin/smbd [0x800dcd86]
   #7 bin/smbd(smbd_process+0x8af) [0x800ddebe]
   #8 bin/smbd(main+0x16d7) [0x804425dc]
   #9 /lib/ [0xb7b97f9c]
   #10 bin/smbd [0x800661e1]
[2007/07/15 23:14:24, 0] lib/fault.c:dump_core(181)
  dumping core in /usr/local/samba3/var/cores/smbd

On 7/15/07, Steve French <smfrench at> wrote:
> jra,
> Running cifs 1.50 (current cifs) on a different machine, this time
> against server code from samba-latest.tar.gz from the web site rather
> than from SAMBA_3_0 svn (which also fails).   I confirmed that the
> posix unlink code (probably on the Samba server side from what I see
> on wireshark and the local fs) doesn't work as expected.   During
> connectathon tests (in particular the cleanup after test9 at the end
> of the "basic" file tests), the cifs client issues a series of posix
> unlink requests for file.0 through file.9 each call succeeds (smb
> status code is zero) interestingly this does not actually delete the
> files so the subsequent rmdir fails although they seem to be hidden
> from FindFirst so subsequent "rm -rf" still fail too).  I have seen
> other cases deleting a single file with "rm" at the command line which
> work using the posix unlink.



More information about the samba-technical mailing list