Hello all, we are experiencing problems with samba 2.0.6 and the MKS touch command. during our builds, we touch files and directories so that our make dependencies work correctly. Unfortunately, it seems that MKS' touch.exe doesn't actually change the time stamp of a file or directory. The command returns without an error, but the timestamp does not change. The same problem exists with samba 2.0.4 and 2.0.5, but we found out that this actually _does_ work with an old machine that still runs samba 1.9.17p3. Our clients are running NT4SP3 and NT4SP5, server is solaris 2.5.1. On the samba side, there are no errors in the log files. On the unix side, I have my file named "xx" $ ls -lu # last access -rwxr--r-- 1 vons users 0 Nov 17 10:18 xx $ ls -lc # last inode modification -rwxr--r-- 1 vons users 0 Nov 17 13:39 xx Executing "f:\mksnt\touch.exe xx" on the client results in the following log messages (debug level = 10): | < .... the file is looked up and opened .... > | [1999/11/17 13:39:45, 6] smbd/trans2.c:(1905) | actime: Wed Nov 17 13:36:24 1999 | modtime: Wed Nov 17 10:18:01 1999 | size: 0 mode: 0 | [1999/11/17 13:39:45, 10] smbd/trans2.c:(1935) | call_trans2setfilepathinfo: setting pending modtime to Wed Nov 17 10:18:01 1999 | < .... file is closed .... > MKS' touch is supposedly updating the access and modification times of a file, but after the "touch", only the Unix inode modification st_ctime is updated (so samba *did* something with the inode), but not the atime or mtime. What surprises me is that the pending mod time is not the current time (13:39), it looks as if the file's mod-time is overwritten with the same old value ?) Secondly, the code states that the modtime is made pending because a subsequent write() will change it anyway: but in our case, the touch command is not going to write anything. Am I running into a bug here, or is this a smb.conf problem ? Gert-Jan ----- "In creating this message no animals were hurt and no Microsoft software was run" - broman@nosc.mil
Heinz Christian wrote:> > ---------- > > From: Gert-Jan Vons[SMTP:vons@ocegr.fr] > > Subject: Samba 2.0.6, MKS' touch.exe, and file/dir time stamps > > > > we are experiencing problems with samba 2.0.6 and the MKS touch > command. > > > > during our builds, we touch files and directories so that our make > > dependencies work correctly. Unfortunately, it seems that MKS' > touch.exe > > doesn't actually change the time stamp of a file or directory. The > > command returns without an error, but the timestamp does not change. > >did you try "nt smb support = false" ?This indeed works around the problem. The only thing is that I'm not sure that I can do this without creating problems elsewhere. We'll see... The problem is still there though, I'll try to find out what is actually happening in the code. Thanks for the work-around, Gert-Jan ----- "In the future, it will become increasingly obvious that your competitors are just as clue-less as you are" - The Dilbert Future
don_mccall@hp.com
1999-Nov-24 21:00 UTC
Samba 2.0.6, MKS' touch.exe, and file/dir time stamps
Hi Peter, et. al; I can reproduce this behavior with the standard NT 4.0 touch command (that you can pull from the NT 4.0 ResourceKit CD) from the command prompt if I map a network drive to my Samba 2.05b HP-UX 11.0 server. But interestingly enough, I did a "touch *" in the directory in question, and ONE file DID reflect the new time, the other didn't. Looking at the debug file for samba, I found the reason why: [1999/11/24 15:04:49, 4] smbd/dosmode.c:(251) set_filetime(anothertestbydon.txt) failed: Not owner Turns out that I was comming in as 'nobody'; I only had one file in the directory I was using to test your problem on, so I did a drag and drop copy of this file (anothertestbydon.txt) and it was called "Copy of anothertestbydon.txt". Of course, since I had just CREATED this copy, 'nobody' owned it. the original file was owned by another user. When I did a "touch *" the file I 'owned' changed timestamp, and the original one did not. Perhaps your issue is related? By the way, I took a netmon trace of the success and failure, and did not see where the reply to the SetFilePathInfo transact2 smb (which is the smb that the NT client sent to request the date change in response to the 'touch' command) in the failing case differed with the one that succeeded - neither returned any error information, which jives with your finding that the command comes back clean, even though the timestamp remains unchanged. Try using smbstatus to see what username you are attached to, and what unix user that maps to, and then see whether changing the ownership on one of the files you are doing a touch on makes a difference... Sorry I ran out of time to investigate if this is reasonable behavior, but I did a quick test by 'touching' a file on an NT 4.0 server share which I did not own, and the timestamp on THAT file did change... Hope this helps, Don
"H.-P. Ermert" <ermert@snafu.de> wrote:>I changed the source of smbd/dosmode.c but this did not change the >behaviour in my case. > >Then I looked for any differences between smbd 2.0.5a and 2.0.6 because >2.0.5a produces correct file times here. > >I found a difference in smbd/trans2.c line 2355 : > >trans2.c in 2.0.5a: > /* write time + changed time, combined. */ > tvs.modtime=MAX(interpret_long_date(pdata+16), > interpret_long_date(pdata+24)); > >trans2.c in 2.0.6: > /* write time + changed time, combined. */ > tvs.modtime=MIN(interpret_long_date(pdata+16), > interpret_long_date(pdata+24)); > >After replacing MIN in the new (2.0.6) file by MAX the filetime after a >touch or when copying a file seems to be ok. I did no further testing >and did not go into further details, hope you can check if this is the >correct place to fix the problem. I will observe the new behaviour after >the patch.I did the same thing (replace MIN by MAX), and this seems to fix our problems as well. I have removed the "nt smb support=false" work-around from my smb.conf, and hope this fix makes it into a future 2.0.7 :)
I was going nuts yesterday because the first comment character in the first line of the smb.conf disappeared. #============================ Share Definitions =============================# The following two entries demonstrate how to share a directory so that two became ============================ Share Definitions =============================# The following two entries demonstrate how to share a directory so that two testparm gave this report: params.c:Parameter() - Invalid parameter name in config. file. params.c:pm_process() - Failed. Error returned from params.c:parse(). Error loading services. Since that particular file has over 1700 parameters, finding the bad one would be difficult. Would it be possible to output the line number and/or the closest section name to make tracking down errors easier? Also, is that a hard-coded limited of 1000 service definitions in testparm.c? Thanks.
I run Samba 2.0.6 on almost stock Red Hat 6.0, and when I put a bogus line on top, it tells me text from the line instead of the failure you experienced. What version do you run, and what was that infamous top line? Steve Litt At 03:19 AM 12/02/1999 +1100, you wrote:>I was going nuts yesterday because the first comment character in >the first line of the smb.conf disappeared. > >#============================ Share Definitions=============================># The following two entries demonstrate how to share a directory so that two> >became > >============================ Share Definitions =============================># The following two entries demonstrate how to share a directory so that two > >testparm gave this report: > >params.c:Parameter() - Invalid parameter name in config. file. >params.c:pm_process() - Failed. Error returned from params.c:parse(). >Error loading services. > >Since that particular file has over 1700 parameters, finding the bad one >would be difficult. > >Would it be possible to output the line number and/or the closest section >name to make >tracking down errors easier? Also, is that a hard-coded limited of 1000 >service definitions >in testparm.c? Thanks. > >
Jeremy Allison
1999-Dec-20 23:13 UTC
Samba 2.0.6, MKS' touch.exe, and file/dir time stamps
Gert-Jan Vons wrote:> > Hello all, > > we are experiencing problems with samba 2.0.6 and the MKS touch command. > > during our builds, we touch files and directories so that our make > dependencies work correctly. Unfortunately, it seems that MKS' touch.exe > doesn't actually change the time stamp of a file or directory. The > command returns without an error, but the timestamp does not change. >Paul Eggert just sent in a wonderful patch to fix this correctly (I wish I had written it :-). If you have had problems with timestamps being incorrectly set with any Samba 2.0.x server I suggest you apply this patch (which I have committed to the CVS tree) and let me know if this fixes the problem. Thanks (and a *big* thanks to Paul !), Jeremy Allison, Samba Team. ------------------cut here------------------------------- Index: smbd/trans2.c ==================================================================RCS file: /data/cvs/samba/source/smbd/trans2.c,v retrieving revision 1.105.2.30 diff -u -r1.105.2.30 trans2.c --- trans2.c 1999/11/24 00:15:45 1.105.2.30 +++ trans2.c 1999/12/20 21:40:41 @@ -1694,14 +1694,25 @@ case SMB_SET_FILE_BASIC_INFO: { + /* Patch to do this correctly from Paul Eggert <eggert@twinsun.com>. */ + time_t write_time; + time_t changed_time; + /* Ignore create time at offset pdata. */ /* access time */ tvs.actime = interpret_long_date(pdata+8); + + write_time = interpret_long_date(pdata+16); + changed_time = interpret_long_date(pdata+24); + + tvs.modtime = MAX(write_time, changed_time); - /* write time + changed time, combined. */ - tvs.modtime=MIN(interpret_long_date(pdata+16), - interpret_long_date(pdata+24)); + /* Prefer a defined time to an undefined one. */ + if (tvs.modtime == (time_t)0 || tvs.modtime == (time_t)-1) + tvs.modtime = (write_time == (time_t)0 || write_time == (time_t)-1 + ? changed_time + : write_time); #if 0 /* Needs more testing... */ /* Test from Luke to prevent Win95 from ------------------cut here------------------------------- -- -------------------------------------------------------- Buying an operating system without source is like buying a self-assembly Space Shuttle with no instructions. --------------------------------------------------------
Possibly Parallel Threads
- MS Excel/NT/Samba timestamp - serious problem, bug?
- Date/time bug in 2.0.5a?
- [LLVMdev] Issues running LLVM tests on Windows + MKS; filed 4 PRs and have patches
- [LLVMdev] Issues running LLVM tests on Windows + MKS; filed 4 PRs and have patches
- Error building Samba 3.0.14a on Solaris 9