APR questions/issues

[Greg Stein <gs...@lyra.org>]

I just ran into a sticking point on the DAV integration dealing with file
locks. How are locks-per-file done with APR? Specifically, if process A
opens file Foo, how do we get process B to block when it tries to open the
same file?

Both ap_lock_t and ap_file_t seem to assume that the lock/file object is
shared between the processes to accomplish the locking procedure. I'm
looking for two independent locks/files/whatever to be created and then to
interlock.

I've listed this in the STATUS file, but figured that I'd call it out here.
APR appears to missing one feature that DAV needs, and one that it would be
nice to have.

*) there does not seem to be a chmod() equivalent. the DAV code uses this to
   set executable flags on files in the repository (e.g. when somebody
   uploads a CGI script, they can then enable it for execution)

*) the DAV code optimizes a "move" on the same dev_t by just doing a rename.
   The ap_finfo_t structure exposes the inode, but not the dev_t. This is
   actually a bit weird, as the inode is specific to the device (in other
   words, why expose it when it isn't unique by itself). I would like to
   keep the optimization based on the dev_t. Any issues with exposing that
   in the finfo structure?


btw, the DAV code is closer to working, but that new lock code that I put
into SDBM gums it all up. The lock database gets opened, holds the lock, and
then we can't open any property databases (the lock is operating per-process
rather than per-file).

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Re: APR questions/issues

[dean gaudet <dg...@arctic.org>]

On Sun, 2 Jul 2000 rbb@covalent.net wrote:

> Chmod is definately not portable.  There are people who have implemtned
> chmod for Windows, but we don't have it.  I really tried a while ago to
> come up with a way to abstract out file permissions, but I never could
> figure it out.  There are two answers.  1)  Figure out how to abstract out
> file permissions.  2)  Use an ifdef.

anything to do with access permissions isn't terribly portable.  
mod_userdir is a fine fine example:

#ifdef WIN32
            /* Need to figure out home dirs on NT */
            return DECLINED;
#else                           /* WIN32 */

-dean

Re: APR questions/issues

[rb...@covalent.net]

On Sun, 2 Jul 2000, Greg Stein wrote:

> I just ran into a sticking point on the DAV integration dealing with file
> locks. How are locks-per-file done with APR? Specifically, if process A
> opens file Foo, how do we get process B to block when it tries to open the
> same file?
> 
> Both ap_lock_t and ap_file_t seem to assume that the lock/file object is
> shared between the processes to accomplish the locking procedure. I'm
> looking for two independent locks/files/whatever to be created and then to
> interlock.

Two answers here.  :-)

1)  This isn't really a portable operation IMHO.  As such, this should be
done inside an ifdef with native code.

2)  If you are using flock or fcntl ap_lock_t's, then you can open the
file, and call ap_create_lock with the same file name.  Perhaps we need to
make a new ap_lock function that will always use flock or fcntl, but I
really don't know how Windows would implement this.

> I've listed this in the STATUS file, but figured that I'd call it out here.
> APR appears to missing one feature that DAV needs, and one that it would be
> nice to have.
> 
> *) there does not seem to be a chmod() equivalent. the DAV code uses this to
>    set executable flags on files in the repository (e.g. when somebody
>    uploads a CGI script, they can then enable it for execution)

Chmod is definately not portable.  There are people who have implemtned
chmod for Windows, but we don't have it.  I really tried a while ago to
come up with a way to abstract out file permissions, but I never could
figure it out.  There are two answers.  1)  Figure out how to abstract out
file permissions.  2)  Use an ifdef.

> *) the DAV code optimizes a "move" on the same dev_t by just doing a rename.
>    The ap_finfo_t structure exposes the inode, but not the dev_t. This is
>    actually a bit weird, as the inode is specific to the device (in other
>    words, why expose it when it isn't unique by itself). I would like to
>    keep the optimization based on the dev_t. Any issues with exposing that
>    in the finfo structure?

Go ahead and put the dev_t in there.  When I wrote the ap_finfo_t, I only
put in what we needed.  We had one place where we were using the inode,
and none where we were using the device.

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------

RE: APR questions/issues

["William A. Rowe, Jr." <wr...@lnd.com>]

> From: dean gaudet [mailto:dgaudet-list-new-httpd@arctic.org]
> Sent: Tuesday, July 25, 2000 9:15 PM
> 
> On Sun, 2 Jul 2000, Greg Stein wrote:
> 
> > *) the DAV code optimizes a "move" on the same dev_t by 
> just doing a rename.
> 
> rename() will fail automatically if you try to do it across devices... the
> kernel does the check for you, so why do you need to check it?
> 
> >    The ap_finfo_t structure exposes the inode, but not the dev_t. This is
> >    actually a bit weird, as the inode is specific to the device (in other
> >    words, why expose it when it isn't unique by itself). I would like to
> >    keep the optimization based on the dev_t. Any issues with exposing that
> >    in the finfo structure?
> 
> wow, inode isn't really portable is it?

>From my notes in src/lib/apr/file_io/win32/filestat.c ...

    /* If my rudimentary knowledge of posix serves... inode is the absolute
     * id of the file (uniquifier) that is returned by NT as follows.
     * user and group could be related as SID's, although this would ensure
     * it's own unique set of issues.  All three fields are significantly
     * longer than the posix compatible kernals would ever require.
     * TODO: Someday solve this, and fix the executable flag below the
     * right way with a security permission test (as well as r/w flags.)
     *
     *     dwVolumeSerialNumber
     *     nFileIndexHigh
     *     nFileIndexLow
     */
    finfo->user = 0;
    finfo->group = 0;
    finfo->inode = 0;
    finfo->device = 0;  /* ### use drive letter - 'A' ? */

So we have a four byte volume and 8 byte file id, which combined are a
unique file.  Correlations to finfo?  use dwVolumeSerialNumber as device?
use nfileindexlow

Re: APR questions/issues

[dean gaudet <dg...@arctic.org>]

On Sun, 2 Jul 2000, Greg Stein wrote:

> *) the DAV code optimizes a "move" on the same dev_t by just doing a rename.

rename() will fail automatically if you try to do it across devices... the
kernel does the check for you, so why do you need to check it?

>    The ap_finfo_t structure exposes the inode, but not the dev_t. This is
>    actually a bit weird, as the inode is specific to the device (in other
>    words, why expose it when it isn't unique by itself). I would like to
>    keep the optimization based on the dev_t. Any issues with exposing that
>    in the finfo structure?

wow, inode isn't really portable is it?

-dean