Re: adding new info to GnomeVFSFileInfo

[Christophe Fergeau <teuf users sourceforge net>]

Le mer 18/09/2002 à 22:02, Ian McKellar a écrit :
> On Wed, 2002-09-18 at 00:44, Christophe Fergeau wrote:
> > > > +	GNOME_VFS_PERM_ACCESS_READABLE   = 1 << 16,
> > > > +	GNOME_VFS_PERM_ACCESS_WRITEABLE  = 1 << 17,
> > > > +	GNOME_VFS_PERM_ACCESS_EXECUTABLE = 1 << 18
> > > 
> > > I think its a good idea to put these flags above the space used by POSIX
> > > in case we want to support flags like SUID in the future. I was a little
> > > concerned that the GnomeVFSFilePermissions might change size, but it
> > > doesn't look like it will on Linux/x86 or Solaris/sparc. Does anyone
> > > know of a platform we support that this will break on?
> > 
> > What is "above the space used by POSIX" ? Is it enough to put them at
> > bits 16 17 and 18, or would you like them to be "higher" ? (I put them
> > there because I didn't know exactly which bits were used). 
> 
> >From looking through my kernel/glibc headers I'm fairly certain that
> only 16 bits are used.

Yeah, I also looked at that, I don't know at all if that is the same on
solaris, or whichever non-linux system you prefer.

> 
> Hmm, you're right - I'm dumb. I just skim-read the access(2) manpage.
> Perhaps make that static function not return a GnomeVFSResult if it has
> no way of detecting errors.

It can, I just have to check errno when I get -1 (I'm just a bit lazy :)

> > > Oh, and the standard style nitpick that you need to put a space between
> > > function names and parens - foo (bar) vs foo(bar).
> > > 
> > 
> > Ok, I'll change that (even if that's ugly :p )
> 
> I'm so used to it these days. It was the coding style at Eazel and now I
> do it everywhere. Its one aspect of the GNU coding style[*] I like. I
> HATE those half-indented { } though :)
> 
> [*] http://www.gnu.org/prep/standards_23.html#SEC23

Yeah, let's start some flames about coding style!! Then we'll go on with
emacs vs vi :)

> 
> Oops - me not reading things closely again, I thought it was tying into
> the ls parsing but it wasn't. You're calling the "access" program on the
> remote server? I don't have one on my machine and I don't think its
> going to be as standard as using "test" with -r -w and -x flags.
> 

Hmm, I got mine with tetex-bin, that's weird. I thought that was a
standard simple wrapper against the access system call. I'll change it
with test since it's indeed not very likely to be installed on most
machines.

> Also we have to think about what "excutable" means in the context of
> GnomeVFS. Seth has grand (in my opinion cracked-out) ideas about remote
> program invocation but until we have some solution there I'm not sure if
> we should expose execute access information through this interface till
> then - for remote files anyway, though perhaps we should so that
> Nautilus can attach emblems and stuff. *shrug*

I have no strong opinion on that. What I'm interested in is getting read
and write info for remote files. For the executable bit, I agree that it
doesn't make much sense. And Nautilus shouldn't consider remote files as
executable since if the user double click on them, nothing will happen
(or at least the user won't get the expected result). So I'll drop the
executable bit for remote locations for now when I update my patch


Christophe