[no subject]
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.
>=20
> >=20
> > Oh, and the standard style nitpick that you need to put a space between
> > function names and parens - foo (bar) vs foo(bar).
> >=20
>=20
> 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
>=20
> > Perhaps this should go into a version of gnome_vfs_parse_ls_lga that
> > accepts a username in libgnomevfs/gnome-vfs-parse-ls.[ch] so that we ca=
n
> > share this code with the ftp method and extfs methods...
> >=20
>=20
> I don't follow you there... I don't see anything in that function which
> can be useful to the ftp method for example. It runs access in a remote
> shell (using ssh specific functions) and parses its output. What could
> go in gnome_vfs_parse_ls_lga is something which would guess the access
> rights for a file by looking at the owner of a file, but I haven't
> written such a function yet.
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.
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*
Ian
--=-4JYNO9AUIKv42t160Xz/
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQA9iNu5dbVTqx8qdj4RAuO/AKDAG3h25fdsteefxVY4KegVAPraigCfUL27
hi35kLM4afApQ1bXv9A2h/Y=
=8Abn
-----END PGP SIGNATURE-----
--=-4JYNO9AUIKv42t160Xz/--
[
Date Prev][Date Next] [
Thread Prev][Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]