A Directory That Can't Be Removed?
 

Somehow, some time a directory, .gvfs, got created in my home directory, it looks like this:
As root, I cannot stat it; I cannot chmod it; I cannot remove it; I cannot do anything with it and I've run dry.

If anybody's got any ideas, I'd appreciate knowing them.

Thanks for that (only place I didn't look, LQ, sheesh!).

I did go on a bug hunt -- looked for man pages (there aren't any), looked at /usr/doc/gvfs-1.12.3 (less than useless), looked all over the place in /usr (found the commands in /usr/bin, no man page, not much info with a -? option). I did a search at Wikipedia (the article which says just about nothing).

Looks like GazL's suggestion (http://www.linuxquestions.org/questi...9/#post4880848) might be the solution, so I created a ~/.xinitrc, added GVFS_DISABLE_FUSE=1 ; export GVFS_DISABLE_FUSE to it and we'll see what happens.

And I still don't know what the heck it's there for and what it actually does.

I hate this kind of stuff.

It is part of a gnome2 environment. It provides to the users gnome applications a filesystem view of configuration options. The filesystem is NOT something that can be backed up, it is also blocked from any access EXCEPT the user.

When the filesystem is not mounted, the directory will appear normal, and can be deleted. But it will also be recreated when gvfs server is started (usually on login).

Oh - gvfs is implemented using FUSE (filesystem in user space).

Since I quit using Gnome (either version 2 or 3) I haven't had problems with it.

OK, thanks for that -- funny thing is, though, GNOME has never touched this box (it isn't even available directly from Slackware). So, I've probably gotten some GNOME-ish thing on here (that I seem to remember some application that needed it, but darned if I can remember what!).

Oh, drat, maybe one of these:
No clue on what's using them, though -- that directory doesn't exist at log in, just after running for a while and, you know, doing work.

I'll have to one-at-a-time a few things and see who's causing it.

Thanks again.

Any or all of the last three (the icon package may not). Also check for gedit as that uses it too. As far as I know, all gnome applications use it.

I'm pretty sure Firefox starts gvfs (and gconfd-2). I don't know of any way to prevent Firefox from using them (which is annoying, because I have no use for either service).

I've never notice firefox starting it. That isn't even a gnome application. Are you using pulse audio perhaps?

If I start Firefox under twm, it starts gconfd-2 but not gvfs. If I start it under xmonad, it starts both (and it is definitely Firefox that is starting gvfs). The notable differences are that xmonad is launched with
which launches dbus with
while with twm, it is started with
and dbus isn't launched until Firefox opens, where it launches as
I am guessing that ConsoleKit and/or dbus are responsible for launching gvfs when Firefox is started, but you may not notice it depending on how your WM/DE is started.

Well, I dunno -- but, the "SBo" at the end of the package names means that it was requirement for some SlackBuiles.org package (and I dunno which one).

At least I know what it is, just haven't gotten around to finding out what's causing it and, for now anyway, that's good enough. Right now, the directory is there but readable and empty, Firefox is running, so, nope, not Firefox, not Thunderbird, not Xfce (fur sure).

Basically, hellwidit.

You might look in the shell scrip /usr/bin/firefox. It is possible some plugin or other is doing it, as firefox itself has no need for it.

This is part of the "cancer" of gnome... things that don't/shouldn't depend on it suddenly do for some reason. And that goes for dbus as well.

This old mail message (http://lists.freebsd.org/pipermail/f...ly/092967.html) indicates it is a screwball environment that causes the problems where gconfd gets started, and it may be starting the rest.