I think I agree with Branko...
The point is we want an APR interface that reflects the conceptual
operations people need to do. And the problem with the current APR
interface is that it reflects the Unix permissions-bit mentality far
too literally -- therefore the more we try to make it "Do The Right
Thing" on non-Unix systems, the less faithfully its interface
represents its actual semantics.
-K
Branko Čibej <brane@xbc.nu> writes:
> 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
---------------------------------------------------------------------
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