I read in the Samba docs that there is a problem with "utime()" when a user updates another users file the modified time cannot be updated. According to the docs, even if it the file has write permissions set for the non-owner. When I attempt to do a test on a files that is mode 777, I create the file as one user, wait a minute, edit it again as another user, and it changes the modified time. This is not using Samba, this is just opening two different XTerms as two different users. However, when a Win95 client writes a file over the top of another on a Samba share, if the user writing did not originally own the file, it will not have the correct modified time, therefore not backing it up as a changed file during the nightly incremental. We are using Samba in a production environment on an SGI Origin 2000. Has anyone else run into this problem, and what did you do to solve it? BTW, force user = is not a good fix in this case, we have many people working on many different (large) projects, and I do not want someone to accidently delete a tree that does not belong to them. -- Erik Van Riper (EV34) Systems / Network Administrator Midway Home Entertainment Inc. San Diego, California (619) 658 9500 (x110) Go player.
dear mr erik (geek) riper, i suspect that the problem you are seeing (file modified times) is the same as that for the person who posted an msvc++ "file changed. reload?" problem (or was it a pre-compiled headers regeneration one?). it might not be, given that there are two users involved. i am aware, for example, that if you log in as user "root" the user/group permissions appear to be enforced, rather than over-ridden. this is not normal for root user access, and threw me a bit first time i got a "SMB file is read only" message. On Wed, 8 Oct 1997, Erik Van Riper wrote:> > I read in the Samba docs that there is a problem with "utime()" when > a user updates another users file the modified time cannot be updated. > According to the docs, even if it the file has write permissions set > for the non-owner. > > When I attempt to do a test on a files that is mode 777, I create > the file as one user, wait a minute, edit it again as another user, > and it changes the modified time. This is not using Samba, this is > just opening two different XTerms as two different users. > > However, when a Win95 client writes a file over the top of another > on a Samba share, if the user writing did not originally own the > file, it will not have the correct modified time, therefore not > backing it up as a changed file during the nightly incremental. > > We are using Samba in a production environment on an SGI Origin 2000. > > Has anyone else run into this problem, and what did you do to solve > it? > > BTW, force user = is not a good fix in this case, we have many people > working on many different (large) projects, and I do not want someone > to accidently delete a tree that does not belong to them. > > > -- > Erik Van Riper (EV34) Systems / Network Administrator > Midway Home Entertainment Inc. San Diego, California > (619) 658 9500 (x110) > Go player. ><a href="mailto:lkcl@switchboard.net" > Luke Kenneth Casson Leighton </a> <a href="http://mailhost.cb1.com/~lkcl"> Lynx2.7-friendly Home Page </a> <br><b> "Apply the Laws of Nature to your environment before your environment applies the Laws of Nature to you" </b>
Erik Van Riper wrote: <much deleted about utime problem>> Has anyone else run into this problem, and what did you do to solve > it?Yes - I ran into the same problem several years back with a Samba share used by multiple users to store PVCS files, as well as just straight copies of source code. If one user overwrote a file belonging to another, the timestamp got set to the current Samba server time, and NOT the actual file timestamp. Because of this, at the time Andrew Tridgell implemented a fix that has been working perfectly for me for the last two years, but which to my knowledge has never been documented. To enable the fix, you need to add "-DUTIME_WORKAROUND=1" to the compiler options in the Samba makefile, and then rebuilt Samba from the source - i.e. do a "make" and "make install". To have the change actually take effect, you will need to have all your affected users log out of the server, and then back in - to ensure that they reload smbd from the new binary. To the Samba team: Maybe someone can document this fix, or better yet, make it an smb.conf option, rather than a compile-time option? Hope this helps! -- Jim Morris (Jim@Morris.net) -------------------------------------------------------------------- If planes were crashing as often as DOS and Windoze, I doubt that anyone but suicidal maniacs would fly...run linux (or solaris-x86, or BSD, or ...) and be done with it.
On Thu, 16 Oct 1997, Jim Morris wrote:> To enable the fix, you need to add "-DUTIME_WORKAROUND=1" to the > compiler options in the Samba makefile, and then rebuilt Samba from > the source - i.e. do a "make" and "make install". To have the change > actually take effect, you will need to have all your affected users > log out of the server, and then back in - to ensure that they reload > smbd from the new binary.This will only work if smbd is being started from inetd. If smbd is running as a daemon, you will need to shut it down and restart it for the new binary to be used. Charlie Brady - Telstra |internet: cbrady@ind.tansu.com.au Network Products |Snail : Locked Bag 6581, GPO Sydney 2001 Australia Platform Technologies |Physical : Lvl 2, 175 Liverpool St, Sydney 2000 IN-Sub Unit - Sydney | Phone: +61 2 9206 3470 Fax: +61 2 9281 1301
On Thu, 16 Oct 1997, Charlie Brady wrote:> > On Thu, 16 Oct 1997, Jim Morris wrote: > > > To enable the fix, you need to add "-DUTIME_WORKAROUND=1" to the > > compiler options in the Samba makefile, and then rebuilt Samba from > > the source - i.e. do a "make" and "make install". To have the change > > actually take effect, you will need to have all your affected users > > log out of the server, and then back in - to ensure that they reload > > smbd from the new binary. > > This will only work if smbd is being started from inetd. If smbd is > running as a daemon, you will need to shut it down and restart it for the > new binary to be used.Oops! Ignore all that UTIME_WORKAROUND stuff. Jeremy Allison just informed me that it breaks all the new share mode code, and that it should and will be removed from the next Samba release... A new fix will be in 1.9.18 though, in its place. /-------------------------------\ | Jim Morris | jim@morris.net | \-------------------------------/