Philip Martin wrote:
>Karl Fogel <kfogel@newton.ch.collab.net> writes:
>
>>>I'll move the code in question into apr_file_set_read_only() in io.c
>>>like so
>>>
>>Even if no one has provided the Win32 know-how in APR yet, we could
>>still at least put the skeleton in place and have the Unix side done.
>>I think that would be better than adding a WIN32 conditional to
>>Subversion, considering that the minimal APR change here is so
>>trivial.
>>
>
>Damn! That means I need to think of a complete interface instead of
>just one function ;-)
>
>Well, Branko suggested
>
> apr_file_(get|set)_perms
> apr_file_(get|set)_read_only
> apr_file_(get|set)_executable
>
>First, APR already has apr_file_set_perms:
>
> apr_status_t apr_file_perms_set(const char *fname, apr_fileperms_t perms);
>
>and it provides apr_stat to get the perms, so that interface is
>complete, and the (possibly buggy!) Unix implementation is
>available. I assume a Win32 implementation could be provided.
>
>Now APR doesn't appear to have a boolean type so in keeping with the
>rest of APR:
>
> #define APR_FILE_ATTRIBUTE_READONLY 0x01
> #define APR_FILE_ATTRIBUTE_EXECUTABLE 0x02
>
> /* Holds or'ed values of APR_FILE_ATTRIBUTE_... */
> typedef apr_int32_t apr_fileattributes_t;
>
> apr_status_t apr_file_set_attributes(char const *fname,
> apr_fileattributes_t attributes);
> apr_status_t apr_file_get_attributes(char const *fname,
> apr_fileattributes_t *attributes);
>
Should be apr_file_attributes_(get|set) to be consistent, but otherwise
this seems the way to go.
>These have fairly obvious implementations in terms of
>apr_file_perms_set and apr_stat on Unix. I assume a Win32
>implementation could be provided.
>
>However, this get/set interface doesn't allow Unix to set readonly
>differently for user, group, world and any attempt to make it do so
>just reinvents apr_file_perms_set.
>
Not exactly. Yes, on Unix these would be implemented in terms of
apr_file_perms_(get|set) .
> So what I don't understand is why
>Win32 cannot simply do the right thing 'under the hood' of
>apr_file_perms_set. This is documented to return APR_INCOMPLETE and
>APR_ENOTIMPL if the platform cannot fully comply. It gets 3 sets of
>read/write/execute flags, Win32 could ignore or extrapolate from those
>as required. If it needs to set an ACL as well as a permission can
>apr_file_perms_set not do that? What exactly is the Win32 readonly and
>executable interface? Can someone with Win32 knowledge contribute?
>Why is more than apr_file_perms_set required?
>
Because the semantics are different. On Win32, setting the read-only bit
is a completely different operation than removing all write access bits
from the file's ACL. For one thing, the FAT file system doesn't support
ACLs, but does have a read-only bit.
Besides, there are other attributes (hidden, archive, system) that don't
even have a Unix equivalent (and setting them on Unix would be a no-op);
OTOH, there's no such thing as an "executable" attribute on Win32.
Permissions and attributes really are different.
(BTW, there are a lot of Unix filesystems that support ACLs, but APR
doesn't know anything about them ...)
--
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:00 2006