httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: APR questions/issues
Date Sun, 02 Jul 2000 15:58:00 GMT
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 Bloom               
406 29th St.
San Francisco, CA 94131

View raw message