apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Magnusson <andreas.ch.magnus...@home.se>
Subject Re: New apr_stat/apr_dir_read behavior
Date Fri, 20 Jan 2006 18:00:29 GMT
Garrett Rooney wrote:
> On 12/12/05, Garrett Rooney <rooneg@electricjellyfish.net> wrote:
> 
> I just documented the use of APR_INCOMPLETE for both apr_stat and
> apr_dir_read, see revision 356615 in the ASF Subversion repository for
> details.  As far as I can tell the incomplete response just means that
> the finfo isn't complete in both cases, so the response (use the valid
> bitmask to check what part's ok) is the correct solution.
> 
> -garrett
> 

Hi all, I've just completed a look into this problem, and this is my 
conclusion:
In APR 0.9.7 (that is delivered with Subversion 1.3.0 on Windows) there 
is a bug in apr_file_open() in that it ignores the flag APR_READCONTROL. 
This is fixed in 1.2.2. This is the thing that causes the whole problem.

But let us take it from the top:
Subversion calls apr_stat(&finfo, path, APR_FINFO_PROT, pool) to see if 
a file is read-only.
apr_stat() calls resolv_ident() which opens the file to get a handle 
which is passed to apr_file_info_get(). It is here the "bug" occurs. In 
0.9.7 the flag APR_READCONTROL isn't used in apr_open_file() which means 
that we cannot call the Win32 GetSecurityInfo() on the handle (done in 
more_finfo()). This means that we call guess_protection_bits() instead, 
which returns something that is quite, but not entirely correct 
(depending on what you were looking for).
In 1.2.2 instead, we manage to call GetSecurityInfo(), and what is 
returned is the rights the auto-group "Everyone" has on the file. Which 
on my machine are none! Why this is done I do not know. But I think that 
is the quest for another discussion, perhaps on the Subversion list.

/Andreas


Mime
View raw message