We have an opportunity here to turn a WinNT machine into a Linux machine. Hurrah! The machine will be used as a file server for developers mostly using VC++. Unfortunately, last time I tried, VC++ makefiles don't work properly on Samba. Everything gets recompiled on a make. The reason as far as I can see is that the makefiles include the object directory as a dependency for each object file. The directory is thus created if it does not exist, but is otherwise untouched; NMAKE (gag - spit) seems to be specially hacked to regard the time of a directory as the creation time. Unix time semantics here don't exactly match Win32, so Samba reports the ctime as the creation time, which is fair enough. Unfortunately, when an object file is written (and I think they are deleted and recreated if they exist) the directory ctime is altered. The directory ctime is thence always the time of the last object file write, so the dependency rule means NMAKE will always rebuild everything :-( Replacing NMAKE isn't an option for us, so I am proposing to add an option to smb.conf to determine how directory creation times are reported. This could be: 1. ctime, as at present (default). 2. earliest ctime of the files in the directory, or ctime if empty. (Prob. too expensive). 3. 1/1/70 or some other specified time. Before I lurch off into this, has anybody else already dealt with this? Or worked around it somehow? If not, any comments on further options and possible nasty side-effects? -- Jim Hague - hague@research.canon.com.au(Work),bears@cix.co.uk(Play) Canon Information Systems Research Australia +61 2 9805 2854
Jim Hague wrote:> > Unix time semantics here don't exactly match Win32, so Samba reports the > ctime as the creation time, which is fair enough. Unfortunately, when an > object file is written (and I think they are deleted and recreated if they > exist) the directory ctime is altered. The directory ctime is thence always > the time of the last object file write, so the dependency rule means NMAKE > will always rebuild everything :-( >This is a really interesting post, as I've been working on the VC++5.x problem for 1.9.18p3. One of the things added for p2 was, when returning a create time, to looks at the ctime, mtime and atime and return the oldest (as that's the best representation we can get for create time). I don't think that'll fix the problem however, as creating a file will update the ctime and mtime, and each directory scan will update the atime.> Replacing NMAKE isn't an option for us, so I am proposing to add an option > to smb.conf to determine how directory creation times are reported. This > could be: > > 1. ctime, as at present (default). > 2. earliest ctime of the files in the directory, or ctime if empty. > (Prob. too expensive). > 3. 1/1/70 or some other specified time. >Finding the earliest time of the files in the directory could be *very* expensive, for a directory with many files.> Before I lurch off into this, has anybody else already dealt with this? Or > worked around it somehow? If not, any comments on further options and > possible nasty side-effects?One of the other issues is getting around the hideous 'file changed' bug - which seems to be triggered by code in VC++ working around a Win95 server bug. As Samba doesn't have ChangeNotify (yet) then VC++ constantly polls the filetimes for all open files and expects a Win95 response (after all, what other servers are there but Win95 and NT ? :-). I'm adding an option for p3, "win95 bug compatibility" which causes Samba to return mtime for atime, and swap the byte order of a date in one return call (as Win95 does) - this seems to make the problem much better (although it does still occasionally occur). Let me know how you get on with this. I'm open to good ideas. This problem should go away when Samba does NT SMB's - as we'll support ChangeNotify. Cheers, Jeremy Allison, Samba Team. -- -------------------------------------------------------- Buying an operating system without source is like buying a self-assembly Space Shuttle with no instructions. --------------------------------------------------------
>One of the things added for p2 was, when returning a create >time, to looks at the ctime, mtime and atime and >return the oldest (as that's the best representation >we can get for create time). I don't think that'll fix >the problem however, as creating a file will update >the ctime and mtime, and each directory scan will update >the atime.Concur. I also considered this, but rejected it for precisely this reason. It might be worth adding as an option, but to be honest I can't think offhand of a circumstance in which it would be useful. Though if you've already put it in, it rather suggests that somebody has.>> 1. ctime, as at present (default). >> 2. earliest ctime of the files in the directory, or ctime if empty. >> (Prob. too expensive). >> 3. 1/1/70 or some other specified time.>Finding the earliest time of the files in the directory >could be *very* expensive, for a directory with many files.Absolutely. I'm disinclined to do it for that reason. A co-worker (hi Luke) has suggested another approach. Have Samba create a file (say, .sambaDirAttributes) whenever it creates a directory or reports the ctime of a directory that doesn't have one. The directory ctime could then be reported as the ctime of this file. It does then raise the question of whether you should try to hide the file. Samba to date has avoided mucking with the file system for its own purposes, so I'm not sure about this, though it would be the closest we could get to a proper create time. What do the Gods think? I won't be starting on this for a few weeks, so there's plenty of time to mull it over. I think the options now are: 1. ctime as now (default). 2. 1/1/70 or some other specified time. 3. oldest of ctime, mtime & atime. 4. special file.>One of the other issues is getting around the hideous >'file changed' bug. - which seems to be triggered by >code in VC++ working around a Win95 server bug. As >Samba doesn't have ChangeNotify (yet) then VC++ >constantly polls the filetimes for all open files >and expects a Win95 response (after all, what other >servers are there but Win95 and NT ? :-).You deny the divinity of Redmond? Yea, verily, you will be cast out into the slime of the unbelievers :-) I'm aware of this problem - and the news that you're working on it is very welcome - but it probably isn't a major issue for us, as the server will be mostly serving command line builds. -- Jim Hague - hague@research.canon.com.au(Work),bears@cix.co.uk(Play) Canon Information Systems Research Australia +61 2 9805 2854