Here are some cases where this may be true. Using access() through an
appropriate gnome-vfs cover may or may not help some of these cases.

* AFS uses ACLs (Access Control Lists) to represent file permissions. Although
it reports user-group-other permissions, they are essentially ignored. So trying
to use these permissions will result in completely incorrect results.

* Native filesystems on un*x systems that support ACLs (for example, Solaris and
other proprietary unixen; and similar functionality is under development for
Linux) because then the real check the kernel uses is the ACLs, not the checks
described above.

* On some systems that have "capabilities" support, a user other than uid 0 may
have permission to real all files via a "capability".

* NFS typically "quashes" UID 0 - that is, being UID 0 on the client machine
does not give you universal read/write capability on the host machine.

* NFS servers may do even more complex UID mappings than that - the client UID
may be mapped to a completely different UID on the server. The access(2) man
page implies that even access() will not return correct results for this case! I
don't really know much about the specifics of this problem though.

* When mounting windows file shares (SMB) on a Linux system, Unix
user/group/owner permissions are approximated, but the server actually uses a
different check, so again looking at the permissions may give incorrect results.

* The permissions of the file may change between when we do the test and when we
do the operation.

* For gnome-vfs file systems like http or ftp, our permissions are not tied to
our unix UID or group at all, but rather to some different model of permissions;
for ftp this could be the user we are logged into the ftp site as, for http it
could be based on an htaccess file on the server (which is essentially a model
like ACLs).



------- Additional Comments From darin@bentspoon.com 2000-05-25 17:14:22 ----

This is OK if inconvenient because we will report the errors well. Of course
it's even better if we handle these better.

Once we find specific cases, we may want to write separate bug reports.



------- Additional Comments From eli@eazel.com 2000-10-16 20:17:51 ----

Batch-assigning QA ownership of remaining bugs to eli@eazel.com



------- Additional Comments From snickell@stanford.edu 2001-07-23 00:35:46 ----

Taking bugs previously assigned to Pavel, assigning them to myself. Will parse
them out at my leisure , but many are GnomeVFS bugs we should look at for 2.0



------- Bug moved to this database by unknown@bugzilla.gnome.org 2001-09-09 20:34 -------