Re: Samba performance
Please resend with a mailer that doesn't wrap at 80 columns :-). Jeremy.
Re: Samba 2.2.8 - Snap Server Support
On Mon, Mar 31, 2003 at 09:30:07AM -0500, Irving Carrion wrote: Currently the snap has a hard time reading Samba's domain users / groups correctly. The patch (I did not write the code) simply fixes this problem. It works fine on W2k servers, but I think it runs on a windows appliance operating system. Not sure though. Yes please, can we look at the patch. Thanks, Jeremy.
Re: tcon torture test
On Sat, Mar 29, 2003 at 08:10:03PM -0600, Christopher R. Hertel wrote: [EMAIL PROTECTED] wrote: If two SessionSetups are sent, each resulting in a separate [V]UID, then does Windows apply correct restrictions to each or does it allow the greater set of permissions? That is: The question doesn't really make sense for SMBwriteX. It is similar to the way write() works in posix - a open file handle can be used in any security context, it doesn't matter what euid you change to before calling write() Ah. Bingo. So the context is based on the file handle. Makes sense. The same thing is true of the RPC handles for printing. Jeremy.
Re: NMBD crashing in 2.2.7a (and 2.2.6, 2.2.5)
On Fri, Mar 28, 2003 at 02:19:48PM +0100, Edgar, Bob wrote:
Hi all,
I've been having a problem with nmbd crashing multiple times per day.
I suspect that the problem is caused by a shell script that tries to
lookup the name for ws to ws4000 to build a DNS reverse table.
It look something like this:
#!/bin/ksh
typeset -Z4 i=0
while (( $i 4000 )); do
host=ws$i
nmblookup $host | awk -v host=$host '
/^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+/ {
printf(%s IN A %s\n, host, $1)
}
'
(( i = i + 1 ))
done
I have a level 10 debug log which I could send if it would be useful.
Let me know if there is any more information I can provide.
I think this is a bug we fixed for 2.2.8. Can you please
try with the updated version.
Thanks,
Jeremy.
Re: use sendfile problems with Windows 95
On Thu, Mar 27, 2003 at 03:01:55PM -0500, Pierre Belanger wrote: Hi, I turned on use sendfile, not too long after (on the next logon) someone called me. His Windows 95 was having trouble opening files on the server. He can explore the shared volume but when trying to open a file, his computer hangs and needs to reboot. I've been using sendfile myself with Samba under Solaris 8 with NT 2000 XP since a long time with no trouble at all. I tested with another Windows 95 box -- same problem. Even after ~ 5 min. the box is still hanged. I'm wondering if Windows 98/ME are also affected by this? I don't have access to Windows ME boxes but I might find a Windows 98 box... I'll post when I am able to test. I generated a level 10 log file, it's 155KB (gzip -9). Someone wants to look at it? (I did not want to post this hughe file here). A log file won't help I don't think. It looks like sendfile is simply overwhelming the Win95 box's ability to process incoming TCP. Windows 95 is broken in many subtle and not-so-subtle ways w.r.t. SMB networking I'm afraid. Turning off sendfile might be your only option. Jeremy.
Re: tdb_pack prototype mismatch in printing/printing.c
On Wed, Mar 26, 2003 at 07:26:58PM +, Waider wrote: It appears that store_queue_struct is expecting a different version of tdb_pack, since it's feeding an extra NULL to tdb_pack in place of the format argument. This causes smbd to explode. (Samba HEAD, as ever) Fixed, thanks. Jeremy.
Re: [Samba] print$ share problem URGENT - BUG
On Wed, Mar 26, 2003 at 10:33:13PM +0100, Stéphane Purnelle wrote: Why I have no answer for my questions ? I repeat the situation : RedHat 8.0 with samba 2.2.8 compiled wiwth ldapsam and acl-support I need the print$ share and this system dont't work. I explain : when I add a driver, the system copy the data to the share, but after the copy, w2k display a message the process cannot finish. If I look in the log of machine, I found a ... === [2003/03/26 14:29:50, 0] lib/fault.c:fault_report(39) INTERNAL ERROR: Signal 11 in pid 16328 (2.2.8) Please read the file BUGS.txt in the distribution [2003/03/26 14:29:50, 0] lib/fault.c:fault_report(41) === Please add the following line to your smb.conf file : panic action = /bin/sleep 9 and reproduce the problem. You will find a sleep process left on the machine. Using ps, find the parent of this process (it will be an smbd process), then attach to it using gdb. Type 'bt' to get a backtrace of the problem and please mail it to the list. Thanks, Jeremy.
Re: [PATCH] Better fix for devicetype?
On Tue, Mar 25, 2003 at 10:02:13PM +1100, Andrew Bartlett wrote: Would this be a better fix for the devicetype problem? It looks like we are putting the strings into the buffer twice, and we are not returning the 'fixed' devicetype for both protocol levels ( NT1 and NT1). What happened here is that jermey 'fixed' a const warning. This meant that this 'in/out' buffer became an 'in' buffer, and we didn't push the correct devicetype back to the wire. Well it wasn't so much a warning as a bug. We were passing quoted strings into that function in some cases, so writing into them was not recommended :-). Jeremy.
Re: msdfs broken in 2.2.8
On Mon, Mar 24, 2003 at 02:30:32PM -0800, Eric Horst wrote:
Hello! With great enthusiasm I upgraded from 2.2.7a to 2.2.8 last week
to get the critical security fix. However, it appears that msdfs is
broken in 2.2.8. Several on the 'samba' list have reported this as
well. Some say it works OK for W2K but not for XP. In my case I know
it doesn't work for XP clients. Testing, switching back and forth from
2.2.7a to 2.2.8 and using various clients it consistently confirms that
2.2.8 doesn't work. I dug through logs, source and the 2.2.7a to 2.2.8
diff and can't see any obvious change that would have broken it. I've
tried hard over the last few days to understand the flow through the
code and find the problem but haven't been successful.
Would a saavy Samba technical person be willing to work with me on
resolving this? I have logs and data but lacking an obvious focal point
for the problem I can't summarize the logs enough to include them in
this message.
Here is the fix for Samba 2.2.8 to make MS-DFS work again with WinXP.
(For once this wasn't my fault :-).
Sorry for the problem,
Jeremy.
Index: smbd/trans2.c
===
RCS file: /data/cvs/samba/source/smbd/trans2.c,v
retrieving revision 1.149.4.98
diff -u -r1.149.4.98 trans2.c
--- smbd/trans2.c 7 Mar 2003 23:35:00 - 1.149.4.98
+++ smbd/trans2.c 25 Mar 2003 23:36:05 -
@@ -3043,7 +3043,7 @@
{
char *params = *pparams;
enum remote_arch_types ra_type = get_remote_arch();
- BOOL NT_arch = ((ra_type == RA_WINNT) || (ra_type == RA_WIN2K));
+ BOOL NT_arch = ((ra_type == RA_WINNT) || (ra_type == RA_WIN2K) || (ra_type ==
RA_WINXP) || (ra_type == RA_WIN2K3));
pstring pathname;
int reply_size = 0;
int max_referral_level;
Re: Large RPC bug found, I think
On Wed, Mar 26, 2003 at 01:58:49AM +, Ronan Waide wrote: Ok, I think I've figured this out, but since I'm relatively new to Samba internals I'm not entirely clear on how to fix it, or what I might break with my fix. In a large RPC call, such as an EnumPrinters 2 call with a big buffer, the DCE/RPC stuff gets split into several SMB messages and tossed into a WriteAndX loop. Running a comparison between Samba/NT4 and NT4/NT4, I noticed the following: * For all RPC traffic, if the RPC is unfragmented Samba sets both RPC_HDR_FIRST and RPC_HDR_LAST flags. NT4 sets neither if there's only as single RPC block. This is in rpc_api_pipe_req (possibly elsewhere). It's easily fixed, but I don't know if setting both flags is required behaviour for some other Windows version. * The RPC bind I'm seeing has a max tx/rx buffer size of 5680 bytes. This is independant of whether I use Samba or NT4 as the client. * NT4 sends RPCs via WriteAndX in chunks of 4292 bytes and 1392 bytes (to make 5680 bytes per pair of WriteAndX requests) using the Raw Pipe Write, so two bytes represent the length of the data and the payload is 4290 bytes. As a side note, this length field throws ethereal off being able to decode these packets, as best I can tell. * Samba sends RPCs chunked as 4096 bytes and 1584 bytes. It's not using the Raw Pipe Write. And now, what I think are bugs as opposed to implementation details: * NT4 only sets PIPE_START_MESSAGE on the very first packet; Samba sets this flag on all packets. * NT4 sets the WriteAndX remaining field to 5680 (max tx size) for the first packet and 1390 (max tx less size of first packet) for the second packet. Samba sets the remaining field to the packet size if PIPE_START_MESSAGE is set, and to zero otherwise. (code in cli_issue_write) * Lastly, from the packet traces it appears as if Samba issues each pair of writes before waiting for a response, while NT only issues a new write once it's got the previous response. I've got as far as getting the PIPE_START_MESSAGE flag working correctly. PIPE_RAW_MODE doesn't appear to be implemented in the low-level SMB write stuff. I'm not clear on a clean way of fixing the remaining field, though. Perhaps someone with a bit more understanding of this code could use the above to determine if I have, in fact, found a bug that needs fixing. What is the bug you're trying to fix ? ie. What is the behaviour that Windows shows that is not correct with the Samba code ? Also, I'd feel happier if you tested and compared with Win2000/WinXP rather than WinNT as NT is rather old these days Jeremy.
Re: Problems with ACLs in 2.2.8
On Mon, Mar 24, 2003 at 08:39:22PM +0100, Jan Houstek wrote: Hi all! I posted this in [EMAIL PROTECTED] but there were no reactions. Particulary I'm interested if anyone observe the same behavior. I'll take a look at this. Jeremy.
Re: msdfs broken in 2.2.8
On Mon, Mar 24, 2003 at 02:30:32PM -0800, Eric Horst wrote: Hello! With great enthusiasm I upgraded from 2.2.7a to 2.2.8 last week to get the critical security fix. However, it appears that msdfs is broken in 2.2.8. Several on the 'samba' list have reported this as well. Some say it works OK for W2K but not for XP. In my case I know it doesn't work for XP clients. Testing, switching back and forth from 2.2.7a to 2.2.8 and using various clients it consistently confirms that 2.2.8 doesn't work. I dug through logs, source and the 2.2.7a to 2.2.8 diff and can't see any obvious change that would have broken it. I've tried hard over the last few days to understand the flow through the code and find the problem but haven't been successful. Would a saavy Samba technical person be willing to work with me on resolving this? I have logs and data but lacking an obvious focal point for the problem I can't summarize the logs enough to include them in this message. Also, would somebody give me a hint as to what portion of the patch fixes the security flaw so that I can at least build a fresh 2.2.7a version which protects us? I'm working on a fix for this. I think I've found it. Give me a few more hours. Jeremy
Re: msdfs broken in 2.2.8
On Mon, Mar 24, 2003 at 02:30:32PM -0800, Eric Horst wrote: Hello! With great enthusiasm I upgraded from 2.2.7a to 2.2.8 last week to get the critical security fix. However, it appears that msdfs is broken in 2.2.8. Several on the 'samba' list have reported this as well. Some say it works OK for W2K but not for XP. In my case I know it doesn't work for XP clients. My fix still doesn't help at the moment... I'm still working on this. Jeremy.
Re: Some notes on IDMAP and GROUPS
On Sun, Mar 23, 2003 at 12:36:27AM +1100, Andrew Bartlett wrote: We should create the right magic in IDMAP to make sure that we always keep this stuff in one record. (ie, the record with the user/group). If not, then create the right ldap magic to cope with our own structural objectClass. I hope that this makes some things clearer. This is a nice design Andrew, thanks. Jeremy.
Re: [Samba] 3.0alpha22 does not execute add user script ?
On Sat, Mar 22, 2003 at 09:51:51PM +0100, Volker Lendecke wrote: Hmm. Just checked. This is definitely a change in behaviour. If you do not want the full winbind functionality, a simple 'add user script' is quite handy. Is there a reason why this does not work anymore as in 2.2? 2.2 added a user if the PDC gave its ok. If you ask me, I'd like the old behaviour back :-) Yes, the old behaviour needs to be restored, it is correct. The reason is that not all Samba appliances are Linux based, or even use PAM, so smbd needs to be able to call an add user script if such is configured no matter what the security mode is set to. The 'appliance' mode was the reason the 'add user script' was added in the first place, that's how it is supposed to work. Whoever changed it please revert the change. Jeremy.
Re: Extended Attributes and Hidden, System, Archive attrs?
On Fri, Mar 21, 2003 at 09:44:26AM +0100, Olaf Fr±czyk wrote: Hi, I remember some time ago several people were discussing about putting the Hidden, System, Archive, Read-Only bits in EAs. Has it been done in 3.0? Will it be in 2.2.x serie? Not done for 2.2., I'm thinking about it for 3.0. Jeremy.
Re: Support for Multiple Data Streams?
On Thu, Mar 20, 2003 at 03:01:51PM -0500, Ken Cross wrote: Samba-folk: Samba apparently does not support Alternate Data Streams/Multiple Data Streams. ADS/MDS are the hidden files associated with the Summary tab on a 2K/XP/.Net version of Windows. A file on a SAMBA_3_0 server does not even display the Summary tab on the Properties page. Is this on anybody's To-Do list? We need POSIX filesystem support for this. Currently no known filesystems on a POSIX system support this. Once they do we'll add it. Jeremy.
Re: Support for Multiple Data Streams?
On Fri, Mar 21, 2003 at 10:12:47AM +1100, Tim Potter wrote: On Thu, Mar 20, 2003 at 03:46:59PM -0500, Ken Cross wrote: Yes, to support it properly, the underlying filesystem should include all streams when you cp/mv/rm/... And a portable backup/restore could be interesting! However, I'm having trouble getting Samba to return goofy names like filename:ADS. It keeps mangling them (even with mangling disabled). What's wrong with extended attributes? They satisfy the portability requirements (modulo some autoconf stuff that is probably required to create a uniform system call interface) and are backed up and restored by dump. You can't seek within them and they are not of arbitrary length. Streams are seekable and are to all intents and purposes another file. Solaris has something similar Jeremy.
Re: rd /s, can't find the file specified (internal reference b1996)
On Wed, Mar 19, 2003 at 10:28:59AM +0200, Nir Soffer wrote: Okay. I was being stupid. Very very stupid, and I apologize. Turns out mangled filenames was disabled. But is this the expected error when manged filenames are disabled? Obviously :-). I'll take a look at what the semantics should be though. Jeremy.
Re: patch for logon time on samba3.0 alpha22
On Thu, Mar 20, 2003 at 08:36:10AM +1100, Andrew Bartlett wrote: On Thu, 2003-03-20 at 01:38, Jianliang Lu wrote: Hi, I've patched the samba3.0 alpha22 for logon_time, now the user's logon time is updated when he logs on successfully. In attachment is the patch. Does NT do this only for file-share connects? Or also for Domain logons? If domain logons also trigger it, then the correct place is 'auth/auth_sam.c'. But watch out, we probably need an option to disable this, as in some PDC/BDC setups, it could entail an expensive LDAP update over a WAN. But nice work - it's the kind of detail I've been meaning to catch up on for a while. Yep - looks good, although not the place I'd put it. I'm looking at adding the code into the auth system to implement the Windows account restrictions (unless it's there in 3.0 and I haven't found it yet, which is possible :-). Jeremy.
Re: Samba on OSX 1.2.4
On Wed, Mar 19, 2003 at 03:27:49PM -0800, Abrahim Kalehzan wrote: Hi there, I'm running Samba 2.2.3 on Apple OS X 10.2.4. Is there any patches or upgrade to go to Samba 2.2.8 for Apple OS X 10.2.4? Apple will be releasing one shortly (not to pre-announce for them). I sent them a custom version of the patch for their source tree yesterday. Jeremy.
Re: rd /s, can't find the file specified (internal reference b1996)
On Sun, Mar 16, 2003 at 06:47:44PM +0200, Nir Soffer wrote: Following up to myself, reproducing this is apparently even simpler than I thought - simply do a: touch nir test test and try to delete it from a DOS command line. It will fail. nirtest123456 fails as well, but nirtest12345 so it seems to filename size related. 13 characters won't work and 12 will. Perhaps it's because something is geared towards 8 characters, a dot, and 3 characters somewhere along the line? Needless to say, it works fine on w2k shares... I can't reproduce this at all on a recent (CVS) build of SAMBA_3_0. Can you give me more details on *exactly* how you reproduce it please ? Jeremy.
Re: [SECURITY] Samba 2.2.8 available for download
On Mon, Mar 17, 2003 at 08:13:15PM +0100, Willi Mann wrote: Is 3.0 also vulnerable? 3.0 is not released yet. 3.0 alphas are vulnerable, the SAMBA_3_0 code in CVS is not. Jeremy.
Re: typos in SAMBA_3_0 CVS
On Mon, Mar 17, 2003 at 11:22:57PM +1100, Andrew Bartlett wrote: Yep - I'm about 2 weeks behind on janitorial duties :-( That's very dangerous. What happens then is someone fixes it differently in 3.0, and then we have a problem. Remember, if a fix is obviously applicable to 3.0 it should *not* be checked into HEAD until the same change is ready to be checked into 3.0. Jeremy.
Re: Question - Latest security alery of samba
On Sun, Mar 16, 2003 at 05:54:17PM +0200, Nir Livni wrote: Any list of affected source files would be appreciated. I have replied to Nir privately off-list. Jeremy.
Re: [PATCH] smbcquotas (client site quota support)
On Thu, Mar 13, 2003 at 12:22:55AM +0100, Stefan (metze) Metzmacher wrote: Hi tridge, here's the patch that adds client site quota support to samba, with a util smbcquotas just like smbcalcs... this is able get and set user quotas and get and set the filesystem quota settings. This looks great ! Once this is in the tree I'll start adding support for getting/setting quotas on the smbd server side of things. Great work ! Thanks ! Jeremy.
Re: [PATCH] smbcquotas (client site quota support)
On Thu, Mar 13, 2003 at 12:48:55AM +0100, Stefan (metze) Metzmacher wrote: At 23:32 12.03.2003 +, [EMAIL PROTECTED] wrote: On Thu, Mar 13, 2003 at 12:22:55AM +0100, Stefan (metze) Metzmacher wrote: Hi tridge, here's the patch that adds client site quota support to samba, with a util smbcquotas just like smbcalcs... this is able get and set user quotas and get and set the filesystem quota settings. This looks great ! Once this is in the tree I'll start adding support for getting/setting quotas on the smbd server side of things. I have allready started with the server site. And the NT part is ready (only a few cleanups are needed) and the unix site works on linux now and I'm working on the other platforms too the next week. (tridge gives me access to IRIX, AIX, SUN machines and I have a testdrive.hp.com account ...) But maybe I'll make it work for platforms with the same quotactl prototype like linux and then we can put it to CVS and you can maybe add an other quota system. I also add vfs_get_quota() and vfs_set_quota() to the vfs layer. so that module writers can add quota support for special quota systems... The way to do the server side is to have a command escape for systems that don't have an easy way to programatically get/set quotas. Like the dfree command parameter. That way we can support all systems that have quotas. Jeremy.
Re: scalability of print_queue_update
On Mon, Mar 10, 2003 at 07:10:10PM +1100, Martin Pool wrote: I've been testing injection of many jobs (thousands) into a print queue, and am noticing that appliance_head samba seems to spend heaps of time in print_queue_update, trying to reconcile the output of lpq with samba's database. Yep. I've been working on this in app-head (our 'day' job :-). In particular, this is causing smbspool to give warnings because print_job_end is taking a long time to complete. (10s for tiny files.) Yep. One approach that was discussed a while ago is to have the lpd notify samba when jobs are completed, deleted, or changed. It could either give all the details sufficient to update the record, or (much simpler) just send an smbcontrol message to rescan the queue. That's hard. Modifying all lpd's out there will not be easy. Another approach, which I suppose is really just skirting the issue, would be to never run the update function while a client is waiting, but rather just at intervals when the timer expires. Possibly a separate smbd process might be forked to do this. Alternatively we might say that 40,000 jobs is a silly number to have queued. :-) I think we can also improve the efficiency of the current code without restructuring it; I'll send a patch for that shortly. Ok, what will this patch do ? This is a very irritating comment :-) I have a simple proof for this that unfortunately won't fit in this margin... :-). Please explain :-). Jeremy.
Re: scalability of print_queue_update
On Tue, Mar 11, 2003 at 12:18:55PM +1100, Martin Pool wrote: I observed that it spends a large fraction of its time in print_parse_jobid, called from traverse_fn_delete, called from print_queue_update. This function is I think called O(n**2) times, because smbd compares every job in the tdb against every job in the print queue. Parsing the string is not terribly expensive, but doing it so many times is. It would be better to parse the jobids just once, when the lpq output is read, and store them in the print_queue_struct. I was just trying to work out the right time to put them in there. Doh ! Yeah, that's a really good idea. Wish I'd thought of it :-). It would make the stress tests of a certain person in Roseville much harder to destroy Samba :-). Jeremy.
Re: valgrind_strlen?
On Tue, Mar 11, 2003 at 04:49:56PM +1100, Martin Pool wrote: Some files have a little valgrind_strlen function in there, I suppose to work around a Valgrind bug. Does anyone know what the bug was? There might be a cleaner solution. Yep, it's a glibc inlining strlen() calls problem, causes a valgrind error. Jeremy.
Re: 3.0a21 and HEAD: only primary group of a domain user is set onsmbd
On Tue, Mar 04, 2003 at 10:38:12PM -0500, Ken Cross wrote: The behavior you're seeing is because LDAP is being used to get the group membership rather that RPC. Last month I posted a patch to fix this, but to my knowledge it hasn't been incorporated. (I'm not bitching, just explaining...) Yes, it's in my inbox - 2 more patches to evaluate and incorporate before it :-). Sorry, Jeremy.
Re: Compiler waring with heimdal-0.5.1
On Mon, Mar 03, 2003 at 10:13:03PM +0100, Juergen Hasch wrote: Hi, I installed heimdal-0.5.1 on my Linux box. When compiling Samba HEAD with gcc 3.2 I get lots of warning messages like these : In file included from include/includes.h:421, from smbd/notify.c:22: /usr/include/heimdal/gssapi.h:625: warning: declaration of `open' shadows a global declaration /usr/include/fcntl.h:70: warning: shadowed declaration is here Anybody else seen this ? This is brokenness in the Heimdal header files, not in Samba. The Heimdal developers need to compile with more warnings set in gcc. Jeremy.
Re: Compiler waring with heimdal-0.5.1
On Mon, Mar 03, 2003 at 10:21:06PM +0100, Love wrote: [EMAIL PROTECTED] writes: Anybody else seen this ? This is brokenness in the Heimdal header files, not in Samba. The Heimdal developers need to compile with more warnings set in gcc. What more then -Wall -Wmissing-prototypes -Wpointer-arith -Wbad-function-cast -Wmissing-declarations -Wnested-externs Yep :-). Please add : -Wshadow -Wstrict-prototypes -Wcast-qual -Wcast-align -Wwrite-strings Jeremy.
Re: file descriptors consumed by printing
On Tue, Mar 04, 2003 at 12:46:28PM +1100, Tim Potter wrote: There's an interesting story about that. (-: At the time I fixed this problem we were in don't touch the 2.2 branch unless it is a critical bug fix, and also in this will be the last version of 2.2 for sure mode. I guess we are still in both those conditions again at the moment! Woo hoo ! Just wait until you see my no-writable strings for 2.2 patch :-). Jeremy.
Re: [PATCH] fix: id_sid cache
On Wed, Feb 26, 2003 at 03:55:49PM +0100, Stefan (metze) Metzmacher wrote: Hi Jeremy, I have a little fix for the id_sid cache, to correct return the sidtype. Hi Stefan, Actually there isn't any point in returning the sidtype here that I can see. We're only after the uid_t or gid_t in these calls. I considered this when I re-wrote the code, but already decided it wasn't needed. Thanks, Jeremy.
Re: file descriptors consumed by printing
On Sun, Mar 02, 2003 at 10:25:27PM -0800, Richard Sharpe wrote: On Mon, 3 Mar 2003, Tim Potter wrote: It's fixed in HEAD. Yeah, well someone forgot their janitorial duties :-) I take it that means 3.0 and HEAD will be seeing your cli_XXX 64 bit fixes shortly. :-) :-) :-). Jeremy.
Re: NT_Create: Anything special I need to know?
On Wed, Feb 26, 2003 at 12:24:09AM -0600, Christopher R. Hertel wrote: I'm going to do a very brief writeup of NT_CREATE_ANDX, but I remember hearing rumors dark lurking daemons. What do I need to know? What is there about this command that should be documented? It's *monstrous*. There are so many special cases, corners and daemons living in there that it's hard to list them all. I'm not sure I can even remember them all, but all we've found are in the smbd code. Jeremy.
Re: Byte range locking
On Fri, Feb 21, 2003 at 10:51:10AM -0800, Srikanta Shivanna wrote: I observed it while running the following modified torture test: Thanks ! That saves me from writing one :-) :-). I'll look into it asap ! Jeremy.
Re: Byte range locking
On Fri, Feb 21, 2003 at 10:51:10AM -0800, Srikanta Shivanna wrote: I observed it while running the following modified torture test: Great test. I've applied a modified version of it to smbtorture in HEAD and fixed the bug in Samba's locking implementation. Thanks ! Jeremy.
Re: [PATCH] fix sid_to_uid() return correct sidtype
On Thu, Feb 20, 2003 at 01:20:14PM +0100, Michael Steffens wrote: Noticed why :) The current caching code does also cache local lookups, meaning that local groups (and machine SIDs when Samba is running as DC) can also occur? Hmm, I'm not sure whether the speed gain for local lookups outweighs the costs of having them wipe winbind SID mapping cache entries. The latter ones look more expensive to me. Hmmm. True, but the local lookups could be going via NIS or another method to a remote server. I also reduced the cache size to 10. Can you test the code in you environment and see if it still gives the speedup you noticed. If not I'll remove the local caching code. Jeremy.
Re: Byte range locking
On Thu, Feb 20, 2003 at 07:50:22PM -0800, Srikanta Shivanna wrote: I noticed a difference in byte range locking behavior between Samba (2.2.x) and Windows 2000 server, basically on Samba 2.2.x with strict locking enabled, a client process which owns a shared byte range lock can write to the locked region, this is not allowed on Windows 2000 server. Is there a reason for this Samba behavior? Is it because of default value of some config option? Can you give me more information on what open modes, access requested etc. from the client Win32 code please ? Thanks, Jeremy.
Re: possible memory leak
On Fri, Jan 24, 2003 at 11:07:49AM -0800, Leo Qiu wrote: Hi, I seem to find some possible memory leaks in Samba code. The patch is attached, Could you guys have a look to check whether it is correct? One of them was, one wasn't. I've added comments to the POSIX_ACL code to make it clearer - thanks ! Jeremy.
Re: [PATCH] fix sid_to_uid() return correct sidtype
On Wed, Feb 19, 2003 at 10:03:57PM +0100, Stefan (metze) Metzmacher wrote: HI all, here's a small fix for returning the correct sidtype in sid_to_uid() and sid_to_gid() this should be applied to all branches with the new uid - sid caching code No attachment - please try again. Jeremy.
Re: [PATCH] fix sid_to_uid() return correct sidtype
On Wed, Feb 19, 2003 at 10:20:35PM +0100, Stefan (metze) Metzmacher wrote: At 21:07 19.02.2003 +, [EMAIL PROTECTED] wrote: On Wed, Feb 19, 2003 at 10:03:57PM +0100, Stefan (metze) Metzmacher wrote: HI all, here's a small fix for returning the correct sidtype in sid_to_uid() and sid_to_gid() this should be applied to all branches with the new uid - sid caching code No attachment - please try again. Jeremy. mailman filtered it out...:-( Actually I made the cache cache the sidtype also. Please check over the code I just checked in... Thanks ! Jeremy.
Re: 3.0 commit policy?
On Thu, Feb 20, 2003 at 11:46:35AM +1100, Martin Pool wrote: What is the commit policy for 3.0? Should all changes be moved from HEAD except ones that are explicitly too risky? Or only bug fixes? What about documentation? Use common sense :-). If it's a new/risky feature - add to HEAD only and wait. If it's a bugfix, then it needs to be in both. Remember we're trying to get to 3.0 stable release, but there are still some more features we need before we're feature complete in 3.0. Jerry the releasemeister can tell us more :-). Jeremy (who is very glad he's no longer doing that job :-)
Re: interesting fact about StrCaseCmp
On Tue, Feb 18, 2003 at 06:23:41PM +1100, Martin Pool wrote: One little malloc() could hardly make it any worse, although I will do a test tomorrow to check. One little malloc() - I'll remind you of that quote later :-). But please do the test, that's the only way we can really be sure if it's a speedup or not. Jeremy.
Re: interesting fact about StrCaseCmp
On Tue, Feb 18, 2003 at 10:49:28PM +0100, Ludolf Holzheid wrote: In the embedded/real time world, malloc() and friends are strongly deprecated as you can't predict how long they will take. They have to go through a linked list of unknown length and may even start a garbage collection. Indeed. That's why I made the One little malloc() joke :-). Jeremy.
Detecting true64
Does anyone know how to detect a truu64 system in configure.in ? I'm going through my patchlist and there is a big optimisation that can be done on systems where the getgrnam() call works (True64 is listed as the only broken system) and I'd like to add this to all branches by adding a BROKEN_GETGRNAM define for True64. Jeremy.
Re: interesting fact about StrCaseCmp
On Tue, Feb 18, 2003 at 11:01:53AM +1100, Martin Pool wrote: StrCaseCmp (and strequal) in HEAD has the interesting side-effect that it only compares the first PSTRING_LEN (1024) bytes of the strings. I suppose comparing strings longer than that is probably a bit unlikely, but it still seems kind of dangerous. Would it be OK to change it to use dynamic allocation? What exactly do you want to do here ? I'm not clear what you mean ? Jeremy.
Re: interesting fact about StrCaseCmp
On Tue, Feb 18, 2003 at 03:23:40PM +1100, Martin Pool wrote: On 18 Feb 2003, [EMAIL PROTECTED] wrote: What exactly do you want to do here ? I'm not clear what you mean? The thing I noticed is that StrCaseCmp (and indeed many charcnv function) truncate strings to 1024 characters. I got here following a Valgrind assertion which may or may not be related, but it certainly seems like a bug. What I was proposing in the first instance was to use talloced or malloced buffers rather than a fixed 1024 byte space. There are already some charcnv routines that do this and in any case it is straightforward to do it for other cases using the standard measure-allocate-copy method. You're not talking about allocating them for every call are you ? We call these functions a lot. Jeremy.
Re: ideas for optimizations with large groups
On Wed, Mar 06, 2002 at 11:24:23AM +, Chris Wakelin wrote:
We had big problems with an upgrade to Samba 2.2.3a on Solaris 8 due
to this groups change. Samba 2.2.2 was fine, but had occassional
oplock problems (hence the desire to upgrade). We have a large number
(~1000) of (sometimes large) NIS groups.
I've patched our version of Samba 2.2.3a in lib/util_getent.c
get_users_in_group() commenting out the line :-
if (strchr(gname,*lp_winbind_separator())) {
(and the lines following the if statement) so that the old
getgrnam() calls are used instead (as they are for winbindd).
This fixes the problem for us, but I'd like strongly to support
David's suggestion that the change to using getgrent() be made a
compile-time option for Tru64 only.
It took some time, but I finally got to this, sorry :-).
Jeremy.
Re: Pushing Samba functions into the kernel
On Thu, Feb 13, 2003 at 11:41:35AM -0800, Richard Sharpe wrote: Hi, I wanted to start a discussion on the following: Implementing some SMB functions in the Kernel, within a Samba base, or, Bending and twisting Samba out of shape. There are a number of reasons for wanting to use the Samba code base, but at the same time, extend it to allow more functions to be pushed into the kernel. Some of the things I want to do are: 1. I would like to take advantage of the header splitting capabilities offered by the raft of current and future Theory of Everything chips, as well as allow zero copy and page flipping code to be useful, and to implement recvfile (the analog of sendfile). Each of these seems to require a slightly different approach to receiving SMBs to the current approach. One that I am thinking of is to have a syscall that receives an SMB or generates a time out or return a socket error in the event of an error. The return from the syscall would be a complete SMB, possibly with the NetBIOS header in a separate buffer, and maybe more. 2. The current sendfile code is great, and is implemented in a better way that I originally implemented it where I currently work. However, I believe that there are more cases where I can use sendfile than what Samba currently knows about. It would be useful to have some infrastructure in Samba for doing this. 3. I would like to move down a path of moving simple functions into the kernel, and this is, in some ways, an extension of point 1 above. It would be useful if the system call that gets an SMB can also implement some subset of SMB in the kernel (although I will want some way to indicate that some FIDs not have this treatment, for example those associated with RPCs). Ok, my feelings on Samba in the kernel are the following. 1). We need to be able to de-multiplex incoming SMB's at the kernel level to get over the W2K Terminal Server problem. 2). A utf8 case-insensitive filesystem (massive performance win). 3). Implement SMBreadX/SMBwriteX in the kernel once a channel has been set up. 4). Allow NT SD's stored in EA's to be interpreted by security code living in the kernel for open decisions. Everything else (IMHO) is better done in user space. Jeremy.
Re: Winbindd limited by select
On Wed, Feb 12, 2003 at 07:36:19AM -0500, Ken Cross wrote: Samba-folk: I've run into a problem with winbindd in both 2.2.x and 3.0 where it just locks up after a while on large, busy networks. We finally tracked down the problem to the fact that the C library select function is limited by default to 256 file descriptors in NetBSD (1024 in FreeBSD, 2048 in Linux). So once 256 (or whatever) smbd processes connected to winbindd, it broke pretty badly and was very hard to kill. This is set at compile-time, not run-time. This line: #define FD_SETSIZE 2048 /* Max # of winbindd connections */ must occur before the first invocation of sys/types. This could be a build option, but it might be much simpler to hard-code it in local.h, which is what I did to fix it. Can somebody check the implications of this on Solaris, HPUX, etc.? Great catch ! I'll fix this asap ! Jeremy.
Re: CVS update: samba/source/printing
On Wed, Feb 12, 2003 at 09:03:44AM -0600, Gerald (Jerry) Carter wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 12 Feb 2003 [EMAIL PROTECTED] wrote: Date: Wed Feb 12 06:38:18 2003 Author: abartlet Update of /data/cvs/samba/source/printing In directory dp.samba.org:/tmp/cvs-serv1930/printing Modified Files: notify.c Log Message: Prevent NULL-pointer induced segfaults. Is tdb_pack in appliance_head different for some reason? apparently so. $ cvs log -r1.9.2.14 tdb/tdbutil.c revision 1.9.2.14 date: 2002/11/27 01:51:43; author: jra; state: Exp; lines: +21 -25 SMBencrypt needs dos codepage also. Change tdb_pack/unpack to take a function pointer applied to all strings if it exists. Jeremy. Sorry about that. I'll watch for these nasty differences more closely in future. Jeremy.
Re: Dual winbind daemons - fix to winbindd_dual.c
On Tue, Feb 11, 2003 at 09:46:44PM -0500, Ken Cross wrote: Samba-folk: The dual winbindd daemon hasn't been working (at least not on NetBSD). It always bombs out with [2003/02/11 10:03:23, 2] tdb/tdbutil.c:tdb_log(582) tdb(unnamed): tdb_open_ex: /var/samba/locks/winbindd_idmap.tdb (0,162792) is already open in this process [2003/02/11 10:03:23, 0] nsswitch/winbindd_idmap.c:winbindd_idmap_init(438) winbindd_idmap_init: Unable to open idmap database and then becomes a zombie. The one-line fix below closes idmap before calling winbind_setup_common. BTW, I haven't really had a chance to test it -- does the dual daemon thing work well? We're using it with success on the HP PSA, but that uses the APPLIANCE_HEAD branch. I'll look at this... Jeremy.
Re: Samba 3.0: vfs_netatalk.c
On Tue, Feb 11, 2003 at 03:23:37PM -0500, Green, Paul wrote: Anthony Liguori [mailto:[EMAIL PROTECTED]] wrote: scandir() (and it's [alpha|version]sort() brethren) is a BSD/Linux-ism and therefore isn't very portable. Since this is in a VFS module (and therefore only optional) I guess this is ok. then Herb Lewis [mailto:[EMAIL PROTECTED]] found this info: IRIX: scandir, scandir64, alphasort, alphasort64 BSD: scandir, alphasort I just checked and neither scandir* nor alphasort* are in POSIX-1996 or POSIX-2001. I'm not trying to build vfs_netatalk here on VOS, but if I was, it looks like I'd be writing some code first. I don't consider these functions portable either. My vote is for sticking with functions in POSIX if at all possible. Indeed. We must remove non-POSIX'isms from the code asap. Jeremy.
Re: Ignoring printer errors
On Mon, Feb 10, 2003 at 11:35:01PM +1100, Andrew Bartlett wrote: I'm wondering, why (in HEAD and 3.0) rpc_server/srv_spoolss_nt.c:_spoolss_enddocprinter_internal() doesn't handle any errors? It sort of makes sense if we don't check the output of running the unix 'lpr' command (due to the separate thread of execution), but now we have back-ends like CUPS, that return real error codes - error codes that could well be used to give real meaning back to clients. In particular, if you were to apply an ACL to a printer in CUPS, currently there is no way for that error (beside the dropped print job) to be handled properly. The client just thinks the job spooled correctly. It should not be that hard to do a proper mapping from CUPS error codes to the W_ERR or NT_STATUS equivalent. Any reason why this hasn't been done, before I find myself knee-deep in printing?... (or does anybody want to help me with the mapping?) Don't change the printing code. You'll regret it :-) :-). I was also thinking this morning in the shower of moving the error returns to full NTSTATUS for all printing returns... Give me a little time :-). Jeremy.
Re: REPOST: Finding group members - fix to winbindd_ads.c
On Sat, Feb 08, 2003 at 09:10:41AM -0500, Ken Cross wrote: Samba-folk: A couple of weeks ago I posted a patch to winbindd_ads.c to change the behavior of WINBINDD_GETGRNAM and WINBINDD_GETGRGID using LDAP. Currently, if you do WINBINDD_GETGRNAM to an NT domain using RPC, you get *all* the members of a group, whether primary or supplemental. The same call to an AD using LDAP just returns supplemental members. My patch causes the call to either an NT domain or AD to return the same thing. There was some discussion about making it a separate call, but I think that'd be a mistake. It seems like they should be consistent. Andrew said to repost a patch if it seems to have been forgotten, so... It's *not* been forgotten :-). Honest ! It's in my inbox, where all the patches due for review (by me at least) live :-). I work on these things on a LIFO basis so sometimes things stay there for a little while :-), but it's *not* been forgotten :-). Jeremy.
Re: Interaction of share modes and file permissions
On Thu, Feb 06, 2003 at 02:26:25PM +, Neil Hoggarth wrote: Consider a file with ownership and mode such that a client has read-only permission on that file. Suppose that this file is open read-only by second client, with a share mode of DENY_WRITE. If the first client attempts to open the file read-write then a question arises: what is the appropriate response by the server? There are multiple reasons why the open should fail (access denied and share mode violation), but the response to the Open AndX request only allows for one reason to be communicated back to the client (I think ...). I raise this issue because Samba (v2.2.7 on Solaris) appears to respond to this circumstance differently than a Windows 2000 system does - Samba reports the share mode problem, whereas Windows reports access denied. Ok, we treat this as a bug. We need to give the same error codes as W2K as far ar humanly possible. I stumbled across this distinction when trying to diagnose a problem with a Windows application called Endnote, which is an academic reference manager. The application responds differently depending on which error code it gets - as a result, multiple readers can simultaneously open an Endnote reference library read-only if it is stored on Windows share, but only one reader at a time can open the same file if it is stored on a Samba share. The fact that the app tries a read-only open on the file if it gets permission denied but doesn't if it encounters a share mode problem is arguably a misfeature of the app, and Samba's choice about how to handle the situation seems just as valid as Windows', but I thought that I'd highlight the difference in case the team think it is worth correcting Samba to make it ape a Windows server more closely. I have network packet captures which I think illustrate the difference between Windows and Samba, which I can provide if anyone is interested Yes please, I would love to see the ethereal capture traces. If you can get them to me asap I'll make sure it gets fixed for 2.2.8. Thanks, Jeremy.
Re: why didn't we use krb5-config???
On Thu, Feb 06, 2003 at 07:27:24PM +0100, Stefan (metze) Metzmacher wrote: Hi Jeremy, I just see that newer version's of heimdal and mit have krb5-config. it would be cool to use it by default if it's available and if not fallback to the current tests Didn't know about it :-). I'll take a look - thanks ! Jeremy.
Re: Solaris fcntl CPU/Lock update
On Mon, Feb 03, 2003 at 07:38:31AM -0800, Jeff Mandel wrote: Here's gdb with bt from two processes 12279 and 12327 root@reiger# gdb /usr/local/samba/bin/smbd 12279 GNU gdb 5.0 Copyright 2000 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as sparc-sun-solaris2.8... /tmp/12279 is not a core dump: File truncated Attaching to program `/usr/local/samba/bin/smbd', process 12279 Reading symbols from /usr/lib/libsec.so.1...done. Loaded symbols for /usr/lib/libsec.so.1 Reading symbols from /usr/lib/libgen.so.1...done. Loaded symbols for /usr/lib/libgen.so.1 Reading symbols from /usr/lib/libsocket.so.1...done. Loaded symbols for /usr/lib/libsocket.so.1 Reading symbols from /usr/lib/libnsl.so.1...done. Loaded symbols for /usr/lib/libnsl.so.1 Reading symbols from /usr/lib/libdl.so.1...done. Loaded symbols for /usr/lib/libdl.so.1 Reading symbols from /usr/lib/libpopt.so.0...done. Loaded symbols for /usr/lib/libpopt.so.0 Reading symbols from /usr/lib/libc.so.1...done. Loaded symbols for /usr/lib/libc.so.1 Reading symbols from /usr/lib/libmp.so.2...done. Loaded symbols for /usr/lib/libmp.so.2 Reading symbols from /usr/platform/SUNW,Sun-Fire-280R/lib/libc_psr.so.1...done. Loaded symbols for /usr/platform/SUNW,Sun-Fire-280R/lib/libc_psr.so.1 Reading symbols from /usr/lib/nss_files.so.1...done. Loaded symbols for /usr/lib/nss_files.so.1 Reading symbols from /usr/lib/nss_ldap.so.1...done. Loaded symbols for /usr/lib/nss_ldap.so.1 Reading symbols from /usr/lib/libpthread.so.1...done. Loaded symbols for /usr/lib/libpthread.so.1 Reading symbols from /usr/local/ldapsdk5/lib/libldap50.so...done. Loaded symbols for /usr/local/ldapsdk5/lib/libldap50.so Reading symbols from /usr/local/ldapsdk5/lib/libssldap50.so...done. Loaded symbols for /usr/local/ldapsdk5/lib/libssldap50.so Reading symbols from /usr/local/ldapsdk5/lib/libssl3.so...done. Loaded symbols for /usr/local/ldapsdk5/lib/libssl3.so ---Type return to continue, or q return to quit--- Reading symbols from /usr/local/ldapsdk5/lib/libnss3.so...done. Loaded symbols for /usr/local/ldapsdk5/lib/libnss3.so Reading symbols from /usr/local/ldapsdk5/lib/libnspr4.so...done. Loaded symbols for /usr/local/ldapsdk5/lib/libnspr4.so Reading symbols from /usr/local/ldapsdk5/lib/libprldap50.so...done. Loaded symbols for /usr/local/ldapsdk5/lib/libprldap50.so Reading symbols from /usr/local/ldapsdk5/lib/libplc4.so...done. Loaded symbols for /usr/local/ldapsdk5/lib/libplc4.so Reading symbols from /usr/local/ldapsdk5/lib/libplds4.so...done. Loaded symbols for /usr/local/ldapsdk5/lib/libplds4.so Reading symbols from /usr/lib/libdb-3.3.so...done. Loaded symbols for /usr/lib/libdb-3.3.so Reading symbols from /usr/lib/libresolv.so.2...done. Loaded symbols for /usr/lib/libresolv.so.2 Reading symbols from /usr/lib/libthread.so.1...done. Loaded symbols for /usr/lib/libthread.so.1 Reading symbols from /usr/lib/librt.so.1...done. Loaded symbols for /usr/lib/librt.so.1 Reading symbols from /usr/lib/libaio.so.1...done. Loaded symbols for /usr/lib/libaio.so.1 sol-thread active. Retry #1: Retry #2: Retry #3: Retry #4: [New LWP1] [New Thread 1 (LWP 1)] Symbols already loaded for /usr/lib/libsec.so.1 Symbols already loaded for /usr/lib/libgen.so.1 Symbols already loaded for /usr/lib/libsocket.so.1 Symbols already loaded for /usr/lib/libnsl.so.1 Symbols already loaded for /usr/lib/libdl.so.1 Symbols already loaded for /usr/lib/libpopt.so.0 Symbols already loaded for /usr/lib/libc.so.1 Symbols already loaded for /usr/lib/libmp.so.2 Symbols already loaded for /usr/platform/SUNW,Sun-Fire-280R/lib/libc_psr.so.1 Symbols already loaded for /usr/lib/nss_files.so.1 Symbols already loaded for /usr/lib/nss_ldap.so.1 Symbols already loaded for /usr/lib/libpthread.so.1 Symbols already loaded for /usr/local/ldapsdk5/lib/libldap50.so Symbols already loaded for /usr/local/ldapsdk5/lib/libssldap50.so Symbols already loaded for /usr/local/ldapsdk5/lib/libssl3.so Symbols already loaded for /usr/local/ldapsdk5/lib/libnss3.so Symbols already loaded for /usr/local/ldapsdk5/lib/libnspr4.so Symbols already loaded for /usr/local/ldapsdk5/lib/libprldap50.so Symbols already loaded for /usr/local/ldapsdk5/lib/libplc4.so Symbols already loaded for /usr/local/ldapsdk5/lib/libplds4.so Symbols already loaded for /usr/lib/libdb-3.3.so Symbols already loaded for /usr/lib/libresolv.so.2 Symbols already loaded for /usr/lib/libthread.so.1 Symbols already loaded for /usr/lib/librt.so.1 Symbols already loaded for /usr/lib/libaio.so.1 [Switching to Thread 1 (LWP 1)] signal handler called (gdb) bt #0 signal handler called #1 0xfecd9794 in __sigprocmask ()
Re: Bottleneck with Winbind and NT ACLs in 2.2.7a
On Tue, Feb 04, 2003 at 02:12:29PM +0100, Michael Steffens wrote: Hi, we are running a big Samba 2.2.7a server with Winbind (100 concurrent users, 600 id mappings created since then) since last weekend. It's running quite well! :) However, users are complaining about Samba being very slow when NT ACL support is enabled. I'm suspecting that winbindd is the bottleneck. In winbindd's log I can see that it has to serve [ug]id to sid requests at a very high frequency. Most of them seem to be triggered by smbd daemons working on POSIX ACLs, and the UIDs and GIDs requested are almost always those of the user running a session. Requests are keeping winbindd busy all the time. And when winbindd is busy talking to DCs, user sessions have to wait for ACL settings to complete. As the ID mappings are static - as soon as they exist - wouldn't it be a good idea to have smbd cache those it has come across in the current session? In the attached patch I have tried to implement such a local mapping cache for smbd. What do you think about it? Damn good idea ! I think I'll look into applying some version of this - thanks ! Jeremy.
Re: heimdal didn't have AP_OPTS_USE_SUBKEY
On Sat, Feb 01, 2003 at 01:01:07PM +0100, Stefan (metze) Metzmacher wrote: Hi Jeremy, the latest HEAD didn't not compile with heimdal on SuSE8.1 because AP_OPTS_USE_SUBKEY is not defined in the heimdal/krb5.h only in the MIT krb5.h :-( is it possible to fix samba that it finally compiles fine? Yes, I haven't finished the HEAD converion to Heimdal yet, because HEAD uses some nasty MIT internals I need to look at converting. Jeremy.
Re: permission upgrade during O_TRUNC
On Wed, Jan 08, 2003 at 11:01:13AM +0100, Steve Hardy wrote: not entirely true again the error in the current code is S - SR = SR H - HR = HR which should be S - SR = S H - HR = H that's all. Still simplifies the code. Ok, I finally got to test this and built a torture tester for this case. The reality is more complex, but you can see how it works by looking at the code I just committed to all branches. Thanks a *lot* for your help on this ! Jeremy.
Re: Will these patches make it into 2.2.8?
On Fri, Jan 31, 2003 at 12:58:45PM +0100, Michael Steffens wrote: Hi Samba team, as 2.2.8 seems to approach now, have the following patches been considered for it? They both don't add functionality, but rather improve robustness, and are platform independent: http://lists.samba.org/pipermail/samba-technical/2002-December/041413.html prevents winbindd from damaging its own idmap TDB on write failures (filesystem full), by rolling back partial changes done by the failed store of mapping. http://lists.samba.org/pipermail/samba-technical/2003-January/041897.html avoids the reconnect delay when DC pipes have died, thus avoids false negatives to be returned to clients, and to be cached. Not a 100%, however. If there is really no DC available at the time of query, it will still happen. But it's an improvement compared to having these false negatives always after a connection died. They are in my inbox queue of things to merge. I have to work on HP printing bugs as my 'day' job priority, but I have not forgotten these and will ensure they get added before 2.2.8. Thanks, Jeremy.
Re: Solaris fcntl CPU/Lock update
On Fri, Jan 31, 2003 at 09:07:23AM -0800, Jeff Mandel wrote: I have followed this fcntl bug closely, and I just applied a T-patch for solaris 8 which brought the kernel 108528-19. This includes the fix for 4735093. This has not fixed the problem of smbd growing to consume all available CPU. Environment is SunOS reiger 5.8 Generic_108528-19 sun4u sparc SUNW,Sun-Fire-280R nss_ldap-203 pam_ldap-137 Here's an excerpt of the truss I've used to diagnose this with sun. 24495/1:*** SUID: ruid/euid/suid = 0 / 3007 / 3007 *** 24495/1:*** SGID: rgid/egid/sgid = 0 / 125 / 125 *** Base time stamp: 1041263328.3198 [ Mon Dec 30 16:48:48 CET 2002 ] 24495/1:psargs: /usr/local/samba/bin/smbd -D -s/usr/local/samba/lib/smb. conf 24495/1: 0.0012 sigprocmask(SIG_SETMASK, 0xFED2AD70, 0xFFBEDF10) = 0 24495/1: set = 0xFFBFFEFF 0x1FFF 0 0 24495/1:oset = 0 0 0 0 24495/1: 0.0016 lwp_kill(1, SIGUSR1)= 0 24495/1: 0.0018 sigprocmask(SIG_SETMASK, 0xFFBEDF10, 0x) = 0 24495/1: set = 0 0 0 0 24495/1: 0.0019 Received signal #16, SIGUSR1 [caught] 24495/1: siginfo: SIGUSR1 pid=24495 uid=0 code=-1 24495/1: 0.0021 setcontext(0xFFBED9C8) 24495/1: 0.0022 sigprocmask(SIG_SETMASK, 0xFED2AD70, 0xFFBEDEB0) = 0 24495/1: set = 0xFFBFFEFF 0x1FFF 0 0 24495/1:oset = 0 0 0 0 24495/1: 0.0025 lwp_kill(1, SIGUSR1)= 0 Please ensure the smbd process is compiled with debug symbols (-g) and then attach to it with gdb and please send in a stack backtrace (bt command in gdb). Thanks, Jeremy. *** Repeats continuously *** Any suggestions?
Re: file change notification issues
On Thu, Jan 23, 2003 at 10:55:12AM -0500, Hal Roberts wrote: The purpose of this mail is to make sure no one else is working on / has already finished hacking samba's file change notification support to support notification of individual file changes. If not, I plan on doing so forthwith. More details: I've been wrestling with samba for the past couple of weeks trying to get it to play nicely with IIS. I've got IIS running with a samba share as the root directory, and everything works well except for asp caching. When running from a samba share, IIS refuses to invalidate any cached asps, even if the cached asp is modified or even deleted or moved. I've finally pegged the problem as samba file change notification support. The cifs reference at: http://www.snia.org/tech_activities/CIFS/ indicates that samba should send back information about which files triggered a notification and why for any directory with notification running (for instance, /test/test.asp and FILE_ACTION_MODIFIED). Samba should send back a list of such file/action records with one record for each file action that triggered the notification, up to the maximum as determined by the parameter count field in the request. If the number of records would be greater that the max allowed, the samba server should return a STATUS_NOTIFY_ENUM_DIR error. The samba notification stuff as written does not keep track of which specific files were changed and just *always* returns the STATUS_NOTIFY_ENUM_DIR error. This approach seems to work fine for handling windows explorer updates, but IIS and presumably other applications just drop these replies as errors. Great detective work ! Actaully this is a bug in IIS. The protocol states that STATUS_NOTIFY_ENUM_DIR is a valid return, if too many files were changed (hmmm. define too many :-). It would be possible to cause this to break on Windows 2000 servers also, but I imagine that under 'normal' circumstances few enough files have changed that this doesn't cause a problem for IIS. I'll have to think on this some more Thanks a *lot* for tracking this down ! Jeremy.
Re: compiler warning in libsmb/clireadwrite.c
On Wed, Jan 29, 2003 at 04:44:06PM +1100, Tim Potter wrote:
Er, should I be worried about this warning?
libsmb/clireadwrite.c: In function `cli_issue_read':
libsmb/clireadwrite.c:54: warning: right shift count = width of type
libsmb/clireadwrite.c: In function `cli_issue_write':
libsmb/clireadwrite.c:301: warning: right shift count = width of type
It's presumably complaining about the size of offset being 32 bits.
static BOOL cli_issue_read(struct cli_state *cli, int fnum,
off_t offset, size_t size, int i)
{
[...]
if (bigoffset)
SIVAL(cli-outbuf,smb_vwv10,(offset32) 0x);
Hmmm. It should really be using an SMB_OFF_T which will be
64-bits on a 64-bit machine.
Jeremy.
Re: compiler warning in libsmb/clireadwrite.c
On Tue, Jan 28, 2003 at 11:28:02PM -0800, Richard Sharpe wrote: Is there a portable way to isolate the upper 32 bits? Check out the #ifdef code in smbd/reply.c Jeremy.
Re: DOS mode bits missing from Folders
On Wed, Jan 22, 2003 at 10:53:17PM +0100, Jean Francois Micouleau wrote: On Wed, 22 Jan 2003, Pagani Jr, Ronald wrote: Why not store DOS bit modes in an accompanying dot file? (The DOS modes then read by smbd if it (the dot file) exists) this idea has already been bitten to death. When you backup files, you have to backup the dot file. Renaming is more complex. What does happen if you delete the file from the unix side and create a new file with the same name ? A more elegant solution is to use EA. Yep - that's on my list of things to do for 3.0.x. :-). Jeremy.
Re: CVS update: samba/source/nsswitch
On Thu, Jan 16, 2003 at 12:50:57PM +1100, Martin Pool wrote: On 16 Jan 2003, Andrew Bartlett [EMAIL PROTECTED] wrote: Win2k has a bug (feature?) where there is a connection reset if there is a second connection from the SAME IP, before the first session-setup. So an unprivileged process on the client can cause a local denial of service just by repeatedly half-opening connections? Yes that's true. The same is true on a Windows box too. Jeremy.
Re: Patch for Samba 2.2.6 2.2.7 to work on OS X
On Thu, Jan 16, 2003 at 01:07:34AM -0500, Michael Bennett wrote: So... comments? Does the patch Do The Right Thing? Think this patch or something similar could get merged sometime? :) I remember looking at this patch. The problem is it does something like : #ifdef *BSD.. new code... #else original code. #endif We don't accept patches that are specific to a particular OS in this way anymore (unless there's a really good reason). The correct way to do this is to add a feature test in configure.in that checks if this function works correctly, that way it gets fixed for all platforms it is broken on. A patch like that would get accepted immediately. Without it, we have to write the feature test. Jeremy.
Re: Change Notification
On Tue, Jan 14, 2003 at 07:49:48AM +0100, Juergen Hasch wrote: [EMAIL PROTECTED] wrote: So if I'm understanding you correctly this is actually a kernel bug - correct ? Can you point me at the areas in the kernel source where the problem occurs so I can see how to make smbd work around it until we get the kernel fixed. No it's Samba receiving a signal from the kernel, but not processing it further inside Samba. In notify_kernel/signal_handler() signals_received gets increased when a change notification is received from the kernel. Now the change notification for this type of event (e.g. copy/ rename/delete...) needs to be processed inside Samba. This is done in process_pending_change_notify_queue() which is called from a few places inside e.g. reply.c. This is not happening for file copy in my test setup here (using the copy command in windows). This means the kernel change notification is no longer active for this type of event, because it needs to be restarted in notify_kernel.c/kernel_register_notify(). Eventually process_pending_change_notify_queue() is called by chance and the received change notification signal gets processed at a later random time. Well it's not called 'by chance'. It's called once smbd gets back to the main loop should notice in the next select that a changenotify has occurred (the select should return -1, errno == EINTR and then the function async_processing() should be called before the next smbd is processed. Can you send me a debug level 10 please of the operation failing, plus an *exact* method of duplicating it (client OS, smb.condf, exact client windows open and what you do to reproduce it). Thanks, Jeremy.
Re: Change Notification
On Mon, Jan 13, 2003 at 11:06:46PM +0100, Juergen Hasch wrote: Jeremy, I'm having problems with change notification in Samba 2.2.x under Linux since you changed the signal handling stuff some time ago. An application I'm using always complains about missing change notification, although it used to work. I always failed to find out what's wrong, but now I know :-) What is happening is that Samba receives a change notification signal from the Linux kernel and sometimes simply does not process it, which means that no further signals will be send by the Kernel (DN_MULTISHOT isn't set) for the same event. Processing of the received signal happens for file rename and delete in but not for copying. In reply.c/reply_write_and_X() I added a call to process_pending_change_notify_queue((time_t)0); and now change notification works again for my testcase here. I'm sure you now a better place where process_pending_change_notify_queue() should go to catch file copy events :-) Can you give me more details please about where smbd is missing the signal ? smbd should not be able to miss these signals, as all they do is set a flag that is then processed inline in the main loop. Please give me more details asap. Thanks, Jeremy.
Re: Change Notification
On Mon, Jan 13, 2003 at 11:39:27PM +0100, Juergen Hasch wrote: Can you give me more details please about where smbd is missing the signal ? smbd should not be able to miss these signals, as all they do is set a flag that is then processed inline in the main loop. Please give me more details asap. For testing I have a simple windows program to activates change notification for a given directory on the Samba side. I can then see what is happening when I copy, remove or delete files (this is what I tested). The Samba server is Suse 8.1 with the latest 2.4 kernel and Samba 2_2 CVS, my client is a W2K WS. When I check the signal_handler() function in notify_kernel.c I can see, that after starting a new smbd I get a signal when I copy/move/delete a file. For copy this happens only once, for rename/delete signal_handler is called every time. When I check the kernel_remove_notify() / kernel_register_notify() functions which have to be called every time after a signal is received, they only get called for move or delete operations. So if I'm understanding you correctly this is actually a kernel bug - correct ? Can you point me at the areas in the kernel source where the problem occurs so I can see how to make smbd work around it until we get the kernel fixed. Jeremy.
Re: [PATCH] trans2 querypathinfo alt name
On Thu, Jan 09, 2003 at 05:07:50PM +0100, Stefan (metze) Metzmacher wrote: Hi Jerry, I noticed that if I'm using MS Access 97 on a NT4 machine I can't access to database files witch are in directories 12 chars, but if I do the same thing on an w2k or NT4 server is works. I see that the respond to the query alt file name call send a mangle name in unicode with termination. but the windows servers didn't send the termination I also wonder why we set the LONG FILE NAMES are in use flag in the SMB HEADER flags2 this is also different to windows... I attache a small patch and a view sniffs Did this patch fix the problem ? I'm investigating this at the moment. Thanks, Jeremy.
Re: recursive mutexes in appl_head winbindd_cm.c?
On Tue, Jan 14, 2003 at 05:25:20PM +1100, Tim Potter wrote: On Sat, Jan 11, 2003 at 01:11:14AM +, [EMAIL PROTECTED] wrote: On Fri, Jan 10, 2003 at 05:31:48PM +1100, Martin Pool wrote: Here's my idea for fixing this in appliance-head, without reworking the mutex reference count. Thanks for that - I've just checked in something close to this. Take a look and let me know... I think I've figured out what the problem is. There can be only one outstanding challenge per IP address so the mutex needs to be around the ServerReqChallenge and ServerAuthenticate2 calls. A short test program confirms this. If I open two cli handles to the same domain controller and perform two ServerReqChallenge calls then two ServerAuthenticate2 calls, both authentications fail with access denied. Performing the authentications immediately after the challenge requests works correctly. Err - do you mean the mutex must look like : get_mutex: ServerReqChallenge ServerAuthenticate2 release_mutex: Just checking :-). Jeremy.
Re: Samba 3.0 Alpha 21 - TZ environment variable.
On Fri, Jan 10, 2003 at 02:04:12PM -0800, P Ranjit Kumar wrote: Hi Samba 3.0 Alpha21 tries to emulate the timegm() call. When it does that, it sets the TZ= before it invokes the mktime() call. However, on HP-UX, setting TZ= makes the timezone to be EST but what we want is GMT for time_t computation. This results in Samba failing to a join a domain. Adding platform specific code (like #ifdef HPUX) isn't something we want to move towards. Does HPUX not have timegm ? If not, can you work out a feature test patch that fixes it for HPUX rather than a platform specific one ? Thanks, Jeremy.
Re: recursive mutexes in appl_head winbindd_cm.c?
On Fri, Jan 10, 2003 at 05:31:48PM +1100, Martin Pool wrote: Here's my idea for fixing this in appliance-head, without reworking the mutex reference count. Thanks for that - I've just checked in something close to this. Take a look and let me know... Thanks, Jeremy.
Re: [PATCH] audit handling of waitpid() status codes
On Thu, Jan 09, 2003 at 05:12:15PM +1100, Martin Pool wrote:
I found a data-corruption bug in ccache a few weeks ago relating to
incorrect handling of wait() status codes, so I thought I would do a
quick check for similar things in Samba.
Part of this (the smbd/chgpasswd.c patch) is incorrect I think.
You have changed the line :
if (WIFEXITED(wstat) == 0) {
...
return False;
}
to
if (WIFEXITED(wstat)) {
...
return False;
}
The man page states :
WIFEXITED(status)
is non-zero if the child exited normally.
This particular clause is meant to catch an error condition
(not a normal exit). I agree it's not good code and could be cleaned
up but this change reverses the return code on password change
success.
Jermy.
Re: oplock breaks
On Thu, Jan 09, 2003 at 06:08:01PM -0600, Steven French wrote: In implementing oplock code in the Linux cifs vfs I noticed that Win2K sends a UID of zero (but non-zero FID and TID) on the oplock break from the server ... this implies that the space of valid fids is not related to the UID. Thus if I thought that it were possible to do more than 64K open instances to a particular Windows server the fids it generates are either unique across a particular tid or unique across a particular tid across a particular TCP connection? and the tids that the server generates are also unrelated to the UID ... I'm not sure you can infer that. Surely it just means that the only thing the Windows client checks on an oplock break request is the FID and TID. Jeremy.
Re: Update on Samba fcntl problem with Solaris?
On Tue, Jan 07, 2003 at 12:00:15PM -0500, Haley, Kevin (K.A.) wrote: Hello, I've read the discussion in the list archives regarding the Solaris fnctl problem which appears to be related to the lingering problem our site is having since recent migration to 2.2.6 for our print server (Solaris 8, smbd processes hanging around with high CPU utilization and truss'ed results showing lots of fcntl operations). Is this bug being entirely handled by Sun? Or will there be a samba update as part of the pending fix? It's a Solaris kernel bug so a Samba update isn't needed. Jeremy.
Re: permission upgrade during O_TRUNC
On Tue, Jan 07, 2003 at 10:53:41AM +0100, [EMAIL PROTECTED] wrote: Hey there, I posted a quick fix for a problem I found with all samba's up to 2.2.7a on the general samba list, which describes the following problem: In Windows, if you create a file with NORMAL attributes and ALWAYS_CREATE, close the file and then re-create it with, say, HIDDEN and ALWAYS_CREATE, the file *should* be upgraded to HIDDEN. The other way around, ie. starting with HIDDEN and re-creating with NORMAL should keep the file as HIDDEN. Currently, samba always keep the original attributes. This causes windows to incorrectly store hidden and system files from in a roaming profile which gets you that stupid popping-up Desktop.ini in new profiles after the second login (because the files are not hidden on the profile directory). Why windows opens the files as non-hidden first is unknown to me :) Anyways, here is a patch that fixes it. I have tried my best to make it as clean as possible but as I know little of samba internals it may be wrong ... This works for me, and stops Desktop.ini appearing all over the place. I haven't found any problems with it yet. Thanks for this - I didn't apply exactly this patch but it inspired me to write something I believe is correct. I applied it to HEAD and 3.0, and will back-port to 2.2.x. Thanks once again ! Jeremy. PS. Andrew Bartlett - we now pass the torture test OPEN #9 when map hidden and map system are set :-).
Re: delete on close problems(Content Filtered by PrivateArk)
On Mon, Jan 06, 2003 at 03:14:51PM +0200, Nir Livni wrote: Samba does not allow user B to open the file for read after user A has opened it for delete_on_close. NT/2K server allows it. My question is why samba allows user A to open delete_on_close after user B opens for read, And does not allow user B open for read after user A opens for delete_on_close. Because that's what W2K does :-). Seriously, check out the torture tester which tries to determine the exact delete-on-close semantics. Samba just mimics the W2K ones. Jeremy.
Re: Winbindd problem enumerating lots of groups
On Sun, Jan 05, 2003 at 07:22:33PM -0500, Ken Cross wrote:
I found and fixed a problem where winbindd had trouble enumerating
*lots* of groups (~2000 in my case). This is in SAMBA_3_0, but it's in
other versions, too.
The problem was in the enum_dom_groups routine in winbindd_rcp.c, line
153:
do {
struct acct_info *info2 = NULL;
uint32 count = 0, start = *num_entries; -- here
start is being re-initialized every time through the loop. It mustn't
be.
The fix is easy - move it to the top of the routine a few lines up:
uint32 start = 0;
Are you sure this is correct ? Yes, start is being initialized
to *num_entries (which starts at zero the first time through the
loop) but then at the bottom of the loop *num_entries is incremented
as so :
(*num_entries) += count;
So the next time around the loop start will be incremented
by count. It is then used as the next group index to fetch
in the call :
status = cli_samr_enum_dom_groups(hnd-cli, mem_ctx2, dom_pol,
start,
0x, /* buffer size? */
info2, count);
The current code looks correct to me. Can you explain better
why you think this is wrong ?
Thanks,
Jeremy.
Re: Winbindd problem enumerating lots of groups
On Sun, Jan 05, 2003 at 11:21:02PM -0500, Ken Cross wrote: Sure, it isn't obvious. start isn't where the list is in number of entries, it's an index into some data structure (coming from the DC, I think). The num_entries would increment by 513 (in my tests), but cli_samr_enum_dom_groups would set start to 7509 after the first call. Basically, cli_samr_enum_dom_groups must manage start once it's initialized to zero. The symptoms that I saw were large numbers of duplicate group names. I have ~2000 groups on this test server, but enum_groups returned 9000. It was because start only got incremented by 513 rather than 7509 each time through the loop. Another good data point is the fact that it was broken before I changed it and worked after. ;-) Understood - thanks ! I've applied it to 3.0 and HEAD. Thanks a *lot*, Jeremy.
Re: Patch for unix extensions
On Wed, Jan 01, 2003 at 01:01:19PM +0100, Simo Sorce wrote: My idea was this: let make it so taht if unix extensions are enabled, then we NEVER resolve the links if we permit link creation. So if unix extensions are true, then all opens set O_NOFOLLOW. Ok if O_NOFOLLOW is defined and exists in the kernel - otherwise it's a nasty security hole waiting to happen. Jeremy.
Re: At least some people appreciate the effort we put in
On Thu, Jan 02, 2003 at 11:45:56AM -0600, Gerald (Jerry) Carter wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 1 Jan 2003, Richard Sharpe wrote: So, while it is clear that there are assholes in the world, there are also those who make it all worth while. Richard, Why are you posting this to the list ? There could be any number of reasons why someone did not respond to your patch. You cannot just assume that someone is being rude. Maybe he/she was or maybe not. Who knows? And what real difference does it make? Would you do it again for someone else? Probably so? Also, it *was* our bug. I always subscribe to the all bugs are our responsibility - after all, we wrote the thing ! I *hate* bugs in my software, I don't care who reports them :-). Jeremy.
Re: Patch for unix extensions
On Fri, Dec 27, 2002 at 07:09:43PM +1100, John Newbigin wrote: If no one has any problems with this patch, can it be applied? John. Original Message Subject: Patch for unix extensions Date: Tue, 03 Dec 2002 09:51:39 +1100 From: John Newbigin [EMAIL PROTECTED] To: [EMAIL PROTECTED] This is a small patch which added a new config option to turn the ensure_link_is_safe check off. This check prevents a client using the unix extensions from creating a symlink which points to a directory outside of the share. Many GUI programs make links from ~ to /tmp which will fail. Gnome requires this to work. This does not strictly have to be a config option but if people want the ensure_link_is_safe semantics then there needs to be some way to turn it on and off. With this patch, Samba 3 should fully support home directories mounted via smb. Sorry, I have some problems with this patch. It allows a client to add a symlink to a Samba share which points to a file elsewhere on the server disk. For example : create a symlink from /home/myhome/p - /etc/passwd. Now as Samba resolves names on the *server* not the client, anyone opening /home/myhome/p using smbclient or a Windows client will get /etc/passwd. This (IMHO) is not desirable. Jeremy.
Re: smbclient and putting files larger than 4GB
On Sun, Dec 29, 2002 at 09:04:33PM -0800, Richard Sharpe wrote: Hi, As a result of a complaint about the above topic I found a bug in libsmb/clireadwrite.c that caused writes to an SMB server to corrupt files larger than 4GB and ignore everthing above 4GB+a bit. I have applied a patch to Samba 2.2.x and Samba-head. The patch has been tested: 1. It copes with files larger than 4GB 2. The data send to a Samba server matches the original data, byte for byte. This is the one that Herb published to the list, right ? If it's not in 3.0 it needs to be there also. Jeremy.
Re: smbclient and putting files larger than 4GB
On Sun, Dec 29, 2002 at 10:43:27PM -0800, Richard Sharpe wrote: Well, Herb fixed some other problems but not that one. BTW, how do I add stuff to 3.0? Which tag should I use? SAMBA_3_0 I've already merged it - thanks ! Jeremy.
Re: Bug and Fix - Follow Up
On Tue, Dec 17, 2002 at 09:01:16PM -0600, Matt Roberts, GRDA wrote:
In my search for the cause of the behavior seen in my earlier post,
I traced the function call path to these two interesting functions,
int source/lib/util.c at about line 133:
BOOL set_global_scope(const char *scope)
{
SAFE_FREE(smb_scope);
smb_scope = strdup(scope);
if (!smb_scope)
return False;
strupper(smb_scope);
return True;
}
const char *global_scope(void)
{
return smb_scope;
}
Since the latter function returns the string 'smb_scope', regardless
of what is in it, wouldn't the first function protect against being
set to a NULL value by rewriting it similar to this?
BOOL set_global_scope(const char *scope)
{
SAFE_FREE(smb_scope);
if (!smb_scope) {
smb_scope = strdup();
return False;
}
smb_scope = strdup(scope);
strupper(smb_scope);
return True;
}
Already committed - thanks !
Jeremy.
Re: Bug in reply_write_and_X?
On Fri, Dec 13, 2002 at 04:47:59PM -0800, Conrad Minshall wrote: I must go work other issues... and hope someone else follows up so EFBIG is dealt with sensibly. I checked in the simple fix (map EFBIG to NT_STATUS_DISK_FULL) so it's not an immediate problem. Jeremy.
Re: patch submission procedure help
On Wed, Dec 11, 2002 at 12:05:43PM -0800, Scott Hammond wrote: Hello, Im a newbie developer and Ive submitted a patch to this list a few days ago. Is this the best method to submit fixes, or what procedure should I follow? Will someone review my fix and add it to the code? http://lists.samba.org/pipermail/samba-technical/2002-December/041226.html It's in my inbox list of fixes to review. Sorry for the delay, but it *will* get looked at. Jeremy.
Re: PATCH: auth module dynamic loading fix
On Wed, Dec 11, 2002 at 03:35:11PM +0100, Stefan (metze) Metzmacher wrote: At 22:46 11.12.2002 +1100, Luke Howard wrote: There was a small nit in the authentication subsystem that prevented dynamic loading of authentication providers. The attached patch fixes this. Hi Luke, I think your patch is wrong, then the builtin module will not be loaded... the attached patch should fix your problem. Applied, thanks ! Jeremy.
Re: smbwrapper/smbsh is now working for Linux 2.4
On Tue, Dec 10, 2002 at 01:27:07PM -0500, [EMAIL PROTECTED] wrote: I have smbwrapper and smbsh working on Debian/woody with the Linux 2.4 kernel and the default C library: libc-2.2.5.so. There is a problem that rears its ugly head with a few programs (segmentation violation, presumably due to some function which is not wrapped properly) but in general, and with most programs, it's working great. Based on search results that I've found, there's been almost no work on getting smbwrapper and smbsh working on Linux 2.4 with glibc during the past couple of years, so I don't know if there's anyone actually interested in this. If anyone is interested, let me know and I'll post the patches and the list of known problems. Yes, I'm interested - please post patches. Pressure of other things has made this a low priority but I'm really happy to apply patches that work for people ! Jeremy.
Re: Bug in reply_write_and_X?
On Mon, Dec 09, 2002 at 08:10:00PM -0800, Conrad Minshall wrote: A local filesystem has to return EFBIG to Samba (per POSIX write system call def'n) and in the Samba source I'm looking at EFBIG isn't used anywhere relevant to a WRITE_ANDX, in particular it isn't in the unix_dos_nt_errmap array. That seems too simple though... what am I missing? Nope, you're not missing anything. It really is just a missing mapping for EFBIG error. That's not one we've ever seen returned before (I guess no one else tested us this way :-). Of course, looking in my POSIX spec and in the Linux man page, there it is :-). Now, the question is, what should it map to ? NT_STATUS_DISK_FULL doesn't seem right as the disk isn't full. Hmmm. Any suggestions or should I look through the NT_STATUS error codes and see what matches best. Of course the best way would be to send the equivalent call to W2K and see what NT_STATUS code it returns Jeremy.
Re: Bug in reply_write_and_X?
On Sat, Dec 07, 2002 at 01:42:18AM -0800, Conrad Minshall wrote:
I'm testing my smb client against Samba on FreeBSD. The server's
local filesystem has a maximum filesize of 16 Terabytes. If my
client attempts a writex with an offset of exactly 16TB then I see
ERRnoaccess rather than ERRdiskfull. Looking at some 3.0 sources, it
appears reply_write_and_X() assumes that if write_file() returns zero
(nwritten) then an access error is presumed and reported. But if the
offset is 16TB minus 1 then one byte is written and ERRdiskfull comes
back.
Actually the line of code you're looking at is misleading :
I presume you're looking at :
if(((nwritten == 0) (numtowrite != 0))||(nwritten 0)) {
END_PROFILE(SMBwriteX);
return(UNIXERROR(ERRDOS,ERRnoaccess));
}
The code return(UNIXERROR(ERRDOS,ERRnoaccess)); doesn't always
mean return ERRnoaccess, this code actually calls a function
that checks the value of the unix errno and maps that to a
Windows error. If no mapping can be made then a default error
of ERRnoaccess is returned.
The interesting question would be, why is the write at 16Tb
not setting an errno that is seen by this code ?
I recently fixed a bug with sign extensions at large file
sizes so I'd be very interested if you could CVS update and
test again. If it still fails than a debug level 10 log would
be very useful here. Alternatively I could pop around to the
Apple campus one night and look into it with you (one of the
benefits of being local :-).
Cheers,
Jeremy.
Re: Code improvment in printing area.
On Wed, Dec 04, 2002 at 02:00:44PM -0800, Arcady Chernyak wrote: Hi. I suggest the following small SAMBA code improvement in printing area. All known SAMBA versions can't return to Windows client any return code after calling print command. I need it therefore I made the following SAMBA changes: 1.Change prototype of function print_job_end (in file proto.h): int print_job_end(int jobid, BOOL normal_close); 2.Add new error into file doserr.h #define ERRfiledeleted 63 /* Your file waiting to be printed was deleted. */ I try to use this code in case of errors happened before calling print command 3.Change function print_job_end in file printing.c: This code change looks pretty good - thanks ! I'll try and adapt it for inclusion in Samba 3.0. Thanks, Jeremy.
Re: STAT_ST_BLOCKSIZE on HP-UX
On Wed, Dec 04, 2002 at 04:48:32PM +0100, Michael Steffens wrote: Hi, noticed that very recently a bunch of patches was checked in the SAMBA_2_2 CVS tree, correcting STAT_ST_BLOCKSIZE to be 512 for a number of platforms. (see configure and configure.in) It remained on 8192 for HP-UX (which is the number given by st_blksize) and which seems to be just as wrong there. The correct unit of st_blocks is 1024, instead. I got this value from the HPUX team (who site near me in Cupertino) but I'll check again Jeremy.
