RE: Drive already connected Error in Windows 2000
are you sure you haven't just broken your net use /persistent:no w2k reconnects your drives as they were last time by default. -Oorspronkelijk bericht- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] a.org]Name ns Green, Paul Verzonden: Sunday, February 02, 2003 4:46 PM Aan: 'Grierson, Garry (UK07)'; [EMAIL PROTECTED] Onderwerp: RE: Drive already connected Error in Windows 2000 (please reply to list) Some standard questions... What service pack level for W2K? What operating system are you running under samba 2.2.7? Do you have a reproducible test case you can post? Anything out of the ordinary in your smb.conf file? Sounds like an operating system resource-limit issue... PG -Original Message- From: Grierson, Garry (UK07) [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 28, 2003 7:45 AM To: [EMAIL PROTECTED] Subject: FW: Drive already connected Error in Windows 2000 The log.smbd file has lots of (No locks available) errors.. Any help? -Original Message- From: Grierson, Garry (UK07) Sent: 28 January 2003 11:36 To: '[EMAIL PROTECTED]' Subject: Drive already connected Error in Windows 2000 I have been successfully running with Samba 2.0.7 for more than a year now but am having problems using version 2.2.7 Drive connections to windows 2000 systems have started coming up with 'Drive already connected' errors. When I look at the SMBD processes running on the samba server there are several deamons running that are not currently used. There is also more than one connection per client machine and I cant seem to kill -15 (or even kill -9) these smbd deamons. Any help would be gratefully appreciated!
RE: permission upgrade during O_TRUNC
Yeah I thought about implementing it the way it's in CVS now but didn't dare touch your code :P, although I just found another instance of attributes changing the whole story goes for READONLY as well ... hmm let me make a table - H - H - S - S - R - R - RH - RH - SH - SH H * - H S * - S R * - R So it seems you can only upgrade the attributes if NONE of the original attributes were set, and if so, you take all of the new attributes. Currently the code always takes the new attributes if you're upgrading system or hidden so you'd get S H - H H S - S and worse: S HR - HR H SR - SR It probably doesn't make much of a difference but hey, you never know :) Makes the code easier too 'cause you get if(old_dos_mode == 0 new_dos_mode != 0) *returned_mode = new_dos_mode Which is even easier (yay!). Sorry for the part misinformation in previous posts :) grtz, Steve -Oorspronkelijk bericht- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]Namens [EMAIL PROTECTED] Verzonden: Wednesday, January 08, 2003 3:10 AM Aan: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Onderwerp: 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: permission upgrade during O_TRUNC
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.
Index: open.c
===
RCS file: /cvsroot/samba/source/smbd/open.c,v
retrieving revision 1.128
diff -u -r1.128 open.c
--- open.c 8 Jan 2003 02:09:14 - 1.128
+++ open.c 8 Jan 2003 09:51:50 -
@@ -717,20 +717,19 @@
* the file attributes need to be changed.
*/
- *returned_mode = (mode_t)0;
+ if(old_dos_mode == (mode_t)0 new_dos_mode != (mode_t)0)
+ *returned_mode = new_dos_mode;
+ else
+ *returned_mode = (mode_t)0;
/* If we're mapping SYSTEM and HIDDEN ensure they match. */
if (lp_map_system(SNUM(conn))) {
if ((old_dos_mode FILE_ATTRIBUTE_SYSTEM) !(new_dos_mode
FILE_ATTRIBUTE_SYSTEM))
return False;
- if (!(old_dos_mode FILE_ATTRIBUTE_SYSTEM) (new_dos_mode
FILE_ATTRIBUTE_SYSTEM))
- *returned_mode = new_mode;
}
if (lp_map_hidden(SNUM(conn))) {
if ((old_dos_mode FILE_ATTRIBUTE_HIDDEN) !(new_dos_mode
FILE_ATTRIBUTE_HIDDEN))
return False;
- if (!(old_dos_mode FILE_ATTRIBUTE_HIDDEN) (new_dos_mode
FILE_ATTRIBUTE_HIDDEN))
- *returned_mode = new_mode;
}
return True;
}
-Oorspronkelijk bericht-
Van: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]Namens Steve Hardy
Verzonden: Wednesday, January 08, 2003 10:42 AM
Aan: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
Onderwerp: RE: permission upgrade during O_TRUNC
Yeah I thought about implementing it the way it's in CVS now
but didn't dare
touch your code :P, although I just found another instance of
attributes
changing the whole story goes for READONLY as well ...
hmm let me make a table
- H - H
- S - S
- R - R
- RH - RH
- SH - SH
H * - H
S * - S
R * - R
So it seems you can only upgrade the attributes if NONE of
the original
attributes were set, and if so, you take all of the new attributes.
Currently the code always takes the new attributes if you're upgrading
system or hidden so you'd get
S H - H
H S - S
and worse:
S HR - HR
H SR - SR
It probably doesn't make much of a difference but hey, you
never know :)
Makes the code easier too 'cause you get
if(old_dos_mode == 0 new_dos_mode != 0)
*returned_mode = new_dos_mode
Which is even easier (yay!). Sorry for the part
misinformation in previous
posts :)
grtz,
Steve
-Oorspronkelijk bericht-
Van: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]Namens
[EMAIL PROTECTED]
Verzonden: Wednesday, January 08, 2003 3:10 AM
Aan: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
Onderwerp: 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 :-).
