Philip Martin wrote:
>Branko ÄŒibej <brane@xbc.nu> writes:
>
>>Philip Martin wrote:
>>
>>> 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.
>>
>
>Stop thinking in terms of bits. All I want is "read-only" or
>"no-write-permission" for the user. I don't care whether it sets bits
>or tweaks an ACL.
>
No, you stop thinking in terms of permissions. "Protection" is not
"denial of permission" (well, it is, but in the sense we're talking
about here). Write-protecting a file is conceptually different from
denying read access to it -- for one thing, a super-user can't override
file protection (except by changing it), but can override access
permissions.
>I want to make a file readonly, I call apr_file_set_readonly(...), it
>does some "magic" on Win32. Why can it not do that same stuff when I
>call apr_file_perms_set(~APR_UWRITE)? Then I don't need two
>interfaces to "read-only", and I can discard apr_file_set_readonly.
>
Because a) that's not what it means, and 2) setting ~APR_UWRITE on Unix
will *not* guarantee that the used can't write to the file! Imagine this:
-rw-rw-rw- 1 brane users 112 Oct 18 00:30 foo.bar
Setting the permissions to -r-rw-rw- doesn't help if i happen do be in
group users, and anyway, it's not wat you want.
(The fact that the flag for accessing permissions is called
APR_FILE_PROT doen't help, of course.)
>
>
>>For one thing, the FAT file system doesn't
>>support ACLs, but does have a read-only bit.
>>
>
>But this is an argument for only one interface, isn't it? On FAT it
>doesn't do ACL stuff, on NTFS it does. Again, it's not visisble
>outside apr_file_perms_set and apr_file_perms_get (or apr_stat or
>whatever its called).
>
No, it's not. It's an argument for having an interface that does what
you mean, on all systems.
>>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.
>>
>
>So we add APR_HIDDEN to apr_file_perms_set and the Unix
>implementation returns APR_ENOTIMPL or APR_EINCOMPLETE. No problem,
>its still just apr_file_perms_set.
>
No! Being hidden from directory listings is not a function of file
permissions, in general.
>>Permissions and attributes really are different.
>>
>
>Well, can you propose an interface? I'm stuck, I can't see it, "it's
>different" is not enough.
>
The interface you proposed was quite, good, actually. The only change
I'd recommend is using a combination of mask and fileattribute
parameters in _set, so that you can change a group of attributes with
one call. Also, I don't think a first implementation has to worry about
flags other than READONLY and EXECUTABLE. At least, those are all
Subversion will initially care about .
Don't get confused by the fact that, on Unix, all of those functions
will be implemented in terms of the apr_flle_perm APIs. That's just an
implementation detail. Win32, Netware, etc. implementations will be
completely 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:01 2006