This page contains a couple of patches (i.e. new features, bugfixes etc.) for the Samba source code. The official release 1.9.18 contains two of these patches: the LM Announce support and the WPS fix. With the default settings for 1.9.18, the LM Announce support will kick in automatically once Samba detects an OS/2 system on the network. The WPS fix on the other hand is not enabled by default, because the Samba team is not quite convinced of its safety for non-OS/2 clients. IMHO there should be no worries but I will add another check to really make sure that this code is only executed when an OS/2 client connects. For now, read below how you can edit the source to enable the fix.
I hope to bring out a patch for 2.0.x in due course, with all my remaining fixes. Hold on please...
If you maintain your Samba server yourself, install the patch of your choice and recompile the binaries. However, if you're not, ask your friendly system administrator to install the patch.
Older patches for 1.9.17p1 and 1.9.17p2 are still available as os2clnt.pat and smb17p2.pat but are not mentioned in the table below.
The official Samba 1.9.17 releases contain fixes for the WPS problem but they are disabled by default. (In fact, versions <= 1.9.17p1 in fact would have made things worse since the OS2_WPS_FIX they contain are incorrect!). The correct fixes can be found in the patches below, for 1.9.17 and higher. I also found a way to avoid the annoying message window "extended attributes cannot be copied" under OS/2. Here's how to make it shut up.
I've got the following patches on offer. Pick the one you want, depending on the Samba version you are using and what fixes you need in the patch:
Samba version: 1.9.16p11 1.9.16p11 1.9.17alpha5 1.9.17p3 1.9.17p4 ------------------------------------------------------------------------------ Workaround for bug in IBM Peer - - X X X ------------------------------------------------------------------------------ Fix for WPS problem X - X X X ------------------------------------------------------------------------------ LM Announce support X X X X X ------------------------------------------------------------------------------ "Auto" LM Announces - - - X X ------------------------------------------------------------------------------ SMBcopy fix - - - X X ------------------------------------------------------------------------------ Fix for timestamp problem - - X X X (Solaris 2.4 and OS/2) ------------------------------------------------------------------------------ Fixes for Amiga (by - - X - - Rask Ingemann Lambertsen) ------------------------------------------------------------------------------ Fixes for creating X - X - - OS/2 version (Samba/2) ------------------------------------------------------------------------------ download download download download download older patch ------------> newer patch (preferred!)
patch -p1 < smb17p4.pat >& out
To apply the patch os2a5.pat, goto the directory samba-1.9.17alpha5/source and execute the command:
patch -p1 < os2a5.pat >& out
To apply the patch os2.pat, go to the directory samba-1.9.16p11/source/ and execute the following command:
patch < os2.pat >& out
Comments on the patches: what does that code do anyway?
I noticed a serious bug in Warp 4 and Warp Connect: they can be crashed by the Samba client (smbclient/SMBCLNT.EXE) over the network! Well, not a complete crash such as a TRAP, but it will bring down the SMB networking part of Warp, "IBM Peer". TCP/IP and IPX both keep running. The bug has been confirmed by IBM and other people. It does not appear to be present in Warp Server.Technical information: (you may skip this if you just want to use the patch!)
When getting/mgetting files from the Warp 4 or Connect machine sometimes that machine crashes (putting files is no problem). It's quite unpredictable. Sometimes it takes a couple of megabytes before it crashes, sometimes it crashes after just a couple of files. The machine doesn't crash completely but the network process PEER.EXE goes down: SYS3175 in DOSCALL1.DLL (an important system library). It looks a bit like the infamous "DIR ..\" bug in NT (which Microsoft first blamed on Samba!). If you have Warp 4 or Connect I would very much appreciate it if you could try and see if you get the same problem. One final note: when smbclient is forced to use one of the older SMB protocols (-m COREPLUS or smaller), the problem is gone. Of course, you'll lose support for long file names then, and many other things.
5-Feb-1998: IBM re-released fixpak IP08406 for "IBM Peer". Click here. Do they fix the problem? I haven't tried them yet but I don't think the problem is gone because the list of fixes doesn't seem to mention this particular problem...
#define OS2_WPS_FIX
The fix works, but every time you drag an object to Samba, the WPS shows a message window telling you that the file will be copied without its extended attributes. That's fine, but you'll have to click "Yes" every time. After a while, you probably get as annoyed as I was. I found a solution in the online documentation (File and Print Client task handbook): add the line
SET CONFIRMLOSTEAS=NO
to your CONFIG.SYS. If you want OS/2 to completely shut up about these extended attributes (I noticed that 4OS/2 prints a harmless "error 282" message when a file is copied without extended attributes; other applications may do that too), do the following: edit \IBMLAN\IBMLAN.INI and find the [requester] section. Edit the digit on position 41 of the wrkheuristics parameter. That should be the one at the utmost right, at the lower row. Change it from 0 (default) to 1. The change will take effect the next reboot. Personally, I leave it to the default. It's only the WPS message window that annoys me.
Technical information: (you may skip this if you just want to use the
patch!)
The problem was that when you dragged a WPS object from the OS/2 desktop
to the Samba share, the name got truncated to 8.3. Somehow, OS/2 believed
that the Samba remote filesystem could not do long filenames. The only
lines that have changed from the previous patch contain the string
ERRcannotopen
(see smb.h and server.c) Although the fix is amazingly
simple, it took me a while to pinpoint the trouble spot. Samba supports
long filenames but not extended attributes. There are 2 bits for this indicating
the server's capabilities in the SMB packet header (Flags2 field)
but it turns out that these are completely ignored by the WPS. This was
the first thing that set me on the wrong foot. The second thing was that
OS/2 communicates with other OS/2 machines using the LANMAN2.1 dialect,
and when it talks to Samba the older LM1.2X002 dialect is negotiated. Only
LANMAN2.1 and newer dialects send a string which indicates the name of
the server's file system (NativeFileSystem[]). Warp of course
sends the string HPFS then, and I thought that perhaps from this
string the client determines that the server supports long filenames. This
turned out not to be the case (fortunately, because I would have hated
to write an implementation of the LANMAN2.1 dialect :-). But help came
from an unsuspected corner, namely Matthieu Willm's OS/2 device driver
for the Linux EXT2 filesystem. Another thing that spurred the investigation
of the problem was that I could borrow 2 machines from my user group, who
weren't doing anything with them over the summer vacation. I used one of
them with tcpdump-smb to 'sniff' the exchange of packets on the Ethernet
between 2 Warp machines. With this setup, I shared several types of drives
from one Warp 4 machine: FAT (which supports extended attributes but not
long filenames), HPFS (which supports both extended attributes and long
filenames) and EXT2FS (which supports long filenames but not extended attributes).
Comparing the traces of the conversations between the machines showed that
OS/2 wants to open a special file called
.+,;=[].. FAT returns
"illegal character in name", HPFS just creates the file and EXT2-OS2 returns
"cannot open file" (error code 110). Before the fix, Samba returned error
code 282 ("extended attributes not supported"). Which would intuitively
be the correct response, but unfortunately it resulted in the 8.3 style
filenames. When I changed Samba's response to the same as what EXT2-OS2
returns (error code 110), everything went smoothly and the problem was
fixed!
Samba servers before version 1.9.18 without patch are 'invisible' to the following clients: Warp 4, Warp Connect, LAN Manager Client for OS/2 and LAN Manager Client for DOS (any others??? JdL). With 'invisible' I mean: if you do a NET VIEW under one of these clients, it doesn't show Samba machines in the list of servers you get. The same is true for the graphical browsers included with Warp 4 (the "File and Print Client Resource Browser") and Warp Connect (whatsitsname?). However, if you do a NET USE x: \\SAMBA\SHARE, you can use that share just fine. So it might not be that much of a problem to you after all. But still, not being able to browse Samba servers is an inconvenience...
Fortunately, we have a fix for this. Andreas Degert (ad@papyrus.hamburg.com) and I implemented source code so that Samba can (optionally) send 'LAN Manager announcements', which are picked up by the aforementioned clients.
For Samba versions <= v1.9.17p2 with their respective patches applied, the following line has to added to Samba's configuration file smb.conf to activate the fix:
lm announce = 60
This sets the interval (in seconds) between LAN Manager Announcement packets that the Samba server will send. One broadcast packet per minute per Samba server should not strain your network, but still, if you want to cut back on these broadcasts, increase the number.
The patches for Samba versions 1.9.17p3 and 1.9.17p4 have a new feature: "Auto" LM Announce. Samba will start sending LM Announcements once it detects OS/2 servers sending such announcements (note: I've been thinking of also automatically sending LM Announcements once a DOS LM or OS/2 client connects to the Samba server). Thus, in an all Windows client environment they will not be sent. I figured that in an OS/2 environment the user wouldn't mind having some additional broadcasts on the network so I decided to set the default to "Auto" (2). You can always change this default. Add the following lines to Samba's configuration file smb.conf (the following values are actually already the default).
lm announce = 2
lm interval = 60
Valid settings for "lm announce" are:
0: never send any LM Announcements 1: always send LM Announcements 2 (or higher): send LM Announcements when other servers are already sending those announcements (default)"lm interval" is the number of seconds in between 2 LM Announcements. Setting it higher means less broadcasts but a longer period before DOS+OS/2 clients detect the Samba server, and v.v. Note that you can set this interval only in steps of 10 seconds (if I'm correct) because of a loop timer in Samba. So "lm interval = 15" will be rounded to 20 seconds. The default for "lm interval" is 60 seconds.
Hopefully the Samba team accepts this feature and the "Auto" default, so that DOS LM and OS/2 users will benefit from it in 1.9.18alpha+ without depending on their Samba sysadmin to manually enable this option. (They did! Jeremy Allison added this fix to his completely rewritten nmbd!)
This timestamp problem was reasonably easy to fix. The "last access" and "last modification" timestamps are now set according to how OS/2 does e.g. a copy on its local disks (by watching the "Details" window). With one exception: the "creation" timestamp is set to the current time because I don't know how to set that timestamp under Unix (if it is even possible)...
Not only DosCopy() makes use of SMBcopy, also the WPS. This
is an even more serious problem, because the bug results in not being able
to copy a file on the remote server to another location on that same remote
server (i.e. hold "Ctrl" while dragging the object). I seem to have fixed
this by problem making sure that the destination path contains a backslash
(see reply.c::reply_copy()). This is to please the routine called
resolve_wildcards().
I don't know why this works, but it seems to have the side effect that
no wildcards can be used anymore. (Actually, I had the impression that
wildcards worked for the unpatched source, but somehow even that I don't
see anymore...). I decided to put in this fix so that at least WPS copying
works; DosCopy()'s with wildcards are much rarer.
Note! Copying a WPS folder on the remote server to another
location on that same remote server is not supported by Samba! You'll get
ERROR
58: the specified server cannot perform the requested action. This
is because "tree copy" is not (yet) implemented. Ugly workaround: you can
copy the folder first to your local disk and then move/copy it the new
location.
Back to "Using Samba with DOS or OS/2"