RE: cvs commit: apache-1.3/src/modules/standard mod_autoindex.c

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

> From: Brian Havard [mailto:brianh@kheldar.apana.org.au]
> Sent: Friday, November 03, 2000 10:12 AM
> 
> On 3 Nov 2000 00:55:29 -0000, wrowe@locus.apache.org wrote:
> 
> >  Log:
> >    Resolve mod_autoindex caching problems by returning the mtime as the
> >    Last-Modified tag, and assigning the ETag.  Already applied to the
> >    Apache 2.0 tree.
 
> I believe this fix relies on a file system behaviour that is not universal,
> that is the mtime of a directory is updated whenever a file in it is
> modified. Of the file systems I have on my machine here (FAT, HPFS, JFS)
> only JFS does this. I'll probably have to special case this on OS/2 as HPFS
> is the most commonly used file system on it. JFS is only available on the
> latest server version of OS/2, v4.5 aka "Warp Server for e-business".
> 

I expected, that's why I asked for comments earlier.

Every unix (true readdir platforms) will support this, correct?
NTFS on NT does.  What about NetWare?

FAT will not.  On 9x it returns ctime (somewhat of a problem, but
no worse than the current unstamped flavor for most proxies and
browser caches.)  On NT the FAT directory returns now(), which isn't 
necessarily a bad idea since we know it's volitale, but there could
be a better exception for it.  I can consistify them within the 
os_stat() function of the Win32 port, to either behavior, or return
simply mtime of 0 and tag the header as volatile rather than stamped.

But what do you observe from OS2 on those older filesystems?  
Would a test for (!mtime) help?

RE: cvs commit: apache-1.3/src/modules/standard mod_autoindex.c

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

> From: Brian Havard [mailto:brianh@kheldar.apana.org.au]
> Sent: Friday, November 03, 2000 10:43 AM
> 
> On FAT & HPFS, the directory's mtime == creation time, it 
> never changes.

I was about to use that for the test, but there is something
odd in Win32... mtime ~= ctime, but the resolution is different.
I haven't tested with stat() (I'm playing around with FindFirstFile()
and GetFileAttributesEx() right at the moment) so I will do that
next, but if we are sure of this behavior with stat, we can most
certainly drop Modified-Time in those cases, saving build time 
conditionals and extra volume type testing.  

I'd argue that although the file timestamp changes for JFS
entries aught to be reported, I'm more concerned with the case that
new files are added and deleted, so the links to those files should
be changing.  It would be good if Last-Modified tag was revised for
these cases, but it's not the end of the world, IMHO.  Your thoughts?

Also, do you have good dev/inode tags of meaningful value from the
stat() call?  Or shall we drop ETag as well, and on what condition?

Finally, what to do when ctime==mtime, or we otherwise know this
patch just won't work.  What tags aught we send to be reasonably
sure the user isn't looking at horribly stale data?  The idea of
prereading the whole tree and stating all it's members makes me
somewhat sick to my stomache :-(

Bill

RE: cvs commit: apache-1.3/src/modules/standard mod_autoindex.c

[Brian Havard <br...@kheldar.apana.org.au>]

On Fri, 3 Nov 2000 09:25:16 -0600, William A. Rowe, Jr. wrote:

>> From: Brian Havard [mailto:brianh@kheldar.apana.org.au]
>> Sent: Friday, November 03, 2000 10:12 AM
>> 
>> On 3 Nov 2000 00:55:29 -0000, wrowe@locus.apache.org wrote:
>> 
>> >  Log:
>> >    Resolve mod_autoindex caching problems by returning the mtime as the
>> >    Last-Modified tag, and assigning the ETag.  Already applied to the
>> >    Apache 2.0 tree.
> 
>> I believe this fix relies on a file system behaviour that is not universal,
>> that is the mtime of a directory is updated whenever a file in it is
>> modified. Of the file systems I have on my machine here (FAT, HPFS, JFS)
>> only JFS does this. I'll probably have to special case this on OS/2 as HPFS
>> is the most commonly used file system on it. JFS is only available on the
>> latest server version of OS/2, v4.5 aka "Warp Server for e-business".
>> 
>
>I expected, that's why I asked for comments earlier.
>
>Every unix (true readdir platforms) will support this, correct?
>NTFS on NT does.  What about NetWare?
>
>FAT will not.  On 9x it returns ctime (somewhat of a problem, but
>no worse than the current unstamped flavor for most proxies and
>browser caches.)  On NT the FAT directory returns now(), which isn't 
>necessarily a bad idea since we know it's volitale, but there could
>be a better exception for it.  I can consistify them within the 
>os_stat() function of the Win32 port, to either behavior, or return
>simply mtime of 0 and tag the header as volatile rather than stamped.
>
>But what do you observe from OS2 on those older filesystems?  
>Would a test for (!mtime) help?

After a bit more testing I've concluded that none of the file systems in
general use on OS/2 update the directory mtime for every change to that
directory that affects the output of the autoindex. Even JFS only updates
the mtime if a file is created or deleted, touching an existing file
doesn't.

On FAT & HPFS, the directory's mtime == creation time, it never changes.

-- 
 ______________________________________________________________________________
 |  Brian Havard                 |  "He is not the messiah!                   |
 |  brianh@kheldar.apana.org.au  |  He's a very naughty boy!" - Life of Brian |
 ------------------------------------------------------------------------------