search for: readdirname

...ic2(1406) BACKTRACE: 14 stack frames: #0 /usr/sbin/smbd(smb_panic2+0x1d2) [0x81da689] #1 /usr/sbin/smbd(smb_panic+0x13) [0x81da4b2] #2 /usr/sbin/smbd [0x81c5d0e] #3 /usr/sbin/smbd [0x81c5d75] #4 /lib/libc.so.6 [0x40200078] #5 /lib/libc.so.6(abort+0x178) [0x402015a8] #6 /usr/sbin/smbd(readdirname+0) [0x81da786] #7 /usr/sbin/smbd(smb_panic+0x13) [0x81da4b2] #8 /usr/sbin/smbd(process_exists+0x70) [0x81da2d1] #9 /usr/sbin/smbd(pidfile_pid+0xac) [0x81c8020] #10 /usr/sbin/smbd(pidfile_create+0x3a) [0x81c80ce] #11 /usr/sbin/smbd(main+0x4dc) [0x823ca74] #12 /lib/libc.so.6(__libc_start_...

Jeremy, I think we found the part of source where the problem resides: smbd/trans2.c +1444 for (i=0;(i<maxentries) && !finished && !out_of_space;i++) { +1445 BOOL got_exact_match = False; +1446 +1447 /* this is a heuristic to avoid seeking the dirptr except when +1448 absolutely necessary. It allows for

...========================================== [2004/07/29 01:01:57, 0] lib/util.c:smb_panic2(1398) PANIC: internal error [2004/07/29 01:01:57, 0] lib/util.c:smb_panic2(1406) BACKTRACE: 3 stack frames: #0 smbd(smb_panic2+0xef) [0x8179111] #1 /lib/libc.so.6(abort+0x18b) [0x4016389b] #2 smbd(readdirname+0) [0x81791d1] [2004/07/29 01:01:57, 0] tdb/tdbutil.c:tdb_log(725) tdb(/var/samba/ntforms.tdb): tdb_reopen: open failed (No such file or directory) [2004/07/29 01:01:57, 0] smbd/server.c:open_sockets_smbd(419) tdb_reopen_all failed. [2004/07/29 01:01:57, 0] lib/util.c:smb_panic2(1398) PANIC:...

...25 20:22:36, 0] lib/util.c:smb_panic2(1406) BACKTRACE: 14 stack frames: #0 nmbd(smb_panic2+0x1d2) [0x80d1254] #1 nmbd(smb_panic+0x13) [0x80d107d] #2 nmbd [0x80bc87a] #3 nmbd [0x80bc8e1] #4 /lib/tls/libc.so.6 [0xb746dc08] #5 /lib/tls/libc.so.6(abort+0x1d5) [0xb746f255] #6 nmbd(readdirname+0) [0x80d1351] #7 nmbd(smb_panic+0x13) [0x80d107d] #8 nmbd(process_exists+0x70) [0x80d0e9c] #9 nmbd(pidfile_pid+0xac) [0x80beb78] #10 nmbd(pidfile_create+0x3a) [0x80bec26] #11 nmbd(main+0x4bc) [0x80600f9] #12 /lib/tls/libc.so.6(__libc_start_main+0xf8) [0xb745b748] #13 nmbd(chro...

.../lib/libnss_dns.1...done. #0 0xc01f45a0 in kill () from /usr/lib/libc.2 (gdb) backtrace #0 0xc01f45a0 in kill () from /usr/lib/libc.2 #1 0xc0191948 in raise () from /usr/lib/libc.2 #2 0xc01d1f7c in abort_C () from /usr/lib/libc.2 #3 0xc01d1fd4 in abort () from /usr/lib/libc.2 #4 0x0010df70 in readdirname () #5 0x001126cc in assert_gid () #6 0x00112830 in set_effective_gid () #7 0x000485a0 in become_gid () #8 0x000485cc in become_id () #9 0x00048ef4 in set_sec_ctx () #10 0x00041770 in change_to_user () #11 0x0005380c in make_connection () #12 0x0002c080 in reply_tcon_and_X () #13 0x00051348 in...

...naming the value is not set to -1. In samba 3.0.11 there was no apparent test of the dirent->d_off field, but in 3.0.12 it performs a telldir after reading the last name and returns NULL if the offset it -1. My understanding is that if you preform a telldir after the readdir, as is found in ReadDirName() in dir.c for 3.0.12+ you are just getting the offset for the next entry. So after the last entry in the directory you will be getting the offset of a non-existent entry, in which case the next readdir would return NULL anyways. Is it necessary to test the offset inside the loop after the read...

Over the weekend I upgraded my IRIX servers to 3.0.13 and have found many strange issues regarding the creation of new folders. When I attempt to add a new folder through the Windows side I get an immediate error dialog box stating "You may not be able to access file created in the folder X:\New Folder." When I select to continue the folder is created, looking on the IRIX side the