Directory ctimes

[Jim Hague]

>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 at research.canon.com.au(Work),bears at cix.co.uk(Play)
Canon Information Systems Research Australia        +61 2 9805 2854