Hi, I know this is an old bug and that it's marked as fixed, but I've
been having exactly the same problem lately on Wily. Is there something
i can do?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/210
** Changed in: gvfs
Importance: Unknown => Medium
--
try to access a .Trash-$USER directory on autofs mounts
https://bugs.launchpad.net/bugs/210468
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bu
** Changed in: gvfs
Status: New => Fix Released
--
try to access a .Trash-$USER directory on autofs mounts
https://bugs.launchpad.net/bugs/210468
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-
This bug was fixed in the package gvfs - 0.99.3-0ubuntu2
---
gvfs (0.99.3-0ubuntu2) intrepid; urgency=low
* debian/patches/91_no_autofs_trashs.patch:
- don't look for trash on autofs mounts, change from Paul Smith on launchpad
(lp: #210468)
-- Sebastien Bacher <[EMAIL PR
Copied to hardy-updates.
** Changed in: gvfs (Ubuntu Hardy)
Status: Fix Committed => Fix Released
--
try to access a .Trash-$USER directory on autofs mounts
https://bugs.launchpad.net/bugs/210468
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscrib
If the messages have stopped appearing in your logs, then the problem
you're having is clearly not related to this bug, since this bug is
about autofs .Trash requests. Bug comments are not really the best way
to ask for help, unless it's about the bug in question. You should
either file a bug aga
I've just tried it and the Trash messages have gone but the machine
still hangs when accessing automounts
Nautilus is maxing the CPU - killing this brings it back until I go into
the automount directories again
Any help greatly appreciated
--
try to access a .Trash-$USER directory on autofs mou
I can also verify that this fixes the problem of extra Trash messages.
I also have to say that I haven't seen the hang issue since I applied my
changes, either. Don't know if it's a coincidence, but I'm happy!
--
try to access a .Trash-$USER directory on autofs mounts
https://bugs.launchpad.net
I have deleted the patched 2.4.0 package in my PPA, as it been made
obsolete by the new 2.5.0 upstream in hardy-proposed.
--
try to access a .Trash-$USER directory on autofs mounts
https://bugs.launchpad.net/bugs/210468
You received this bug notification because you are a member of Ubuntu
Bugs, w
** Tags added: verification-done
** Tags removed: verification-needed
--
try to access a .Trash-$USER directory on autofs mounts
https://bugs.launchpad.net/bugs/210468
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mail
Did a very quick check, and it seem to work. The Trash behave as
expected: show full when something is deleted in one of the autofs
mount, we can empty trash just fine and we do not get the error in the
log anymore. Looks good to me!
--
try to access a .Trash-$USER directory on autofs mounts
ht
Accepted into -proposed, please test and give feedback here. Please see
https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to
enable and use -proposed. Thank you in advance!
** Changed in: gvfs (Ubuntu Hardy)
Status: Triaged => Fix Committed
Target: ubuntu-8.04.1 =>
the patch attached to this bug has been added to the 0.2.5 update
--
try to access a .Trash-$USER directory on autofs mounts
https://bugs.launchpad.net/bugs/210468
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing l
Above comment should read "..., there is *no* mention of this bug being
fixed...". Sorry for the confusion!
--
try to access a .Trash-$USER directory on autofs mounts
https://bugs.launchpad.net/bugs/210468
You received this bug notification because you are a member of Ubuntu
Bugs, which is subsc
Looking at the ChangeLog of GVFS 0.2.5, there is mention of this bug
being fixed. A casual inspection of the code confirm it. Sebastien,
did a patch to fix this bug was added to the package you uploaded?
--
try to access a .Trash-$USER directory on autofs mounts
https://bugs.launchpad.net/bugs/
I've uploaded it but the updates are frozen for 8.04.1 right now, it
should be accepted in a few days normally
--
try to access a .Trash-$USER directory on autofs mounts
https://bugs.launchpad.net/bugs/210468
You received this bug notification because you are a member of Ubuntu
Bugs, which is sub
Hi Sebastien; not sure what this means, to be uploaded as a hardy update
candidate... I haven't seen anything come through in my -proposed
repository. Or is this a prelude to that? I guess someone will update
the bug if/when the fix migrates into the repositories?
Thanks.
--
try to access a .T
the new stable version has been uploaded as an hardy update candidate
now
--
try to access a .Trash-$USER directory on autofs mounts
https://bugs.launchpad.net/bugs/210468
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs m
Thanks Etienne. Someday I'm going to learn how to use Launchpad PPA!
As for the fix, I'll say this: first, the concept behind the patch is
unquestionably 100% correct. As you point out, it's fundamentally wrong
to look for .Trash directories in automount points, because they aren't
"real" direct
I built a gvfs package for hardy using the patch Paul Smith posted
above. You can get it from:
https://edge.launchpad.net/~etienne-goyer-outlands/+archive
I am fairly certain the patch is correct, as there is no point in actually
polling for a trash in an autofs base mountpoint anyway. Fi
Here is a bog-simple patch I created for gvfs-0.2.4 that skips any root
directory with a filesystem type of "autofs".
To my mind this is just a workaround: the real answer is that the list
of filesystem types to skip should be configurable, I presume via an
entry in gconf. However, that involves
Just to comment further, I have a remote home directory that I like to be able
to access from
my Ubuntu box. In particular I have an sshfs+autofs setup:
/etc/auto.master:
/autofs/sshfs/cs_student/home auto_home_sshfs -nobrowse
where auto_home_sshfs is a shell script in /etc :
#!/bin/b
Just a comment on point (c) above: I don't think this is quite as
innocuous as you suppose. While looking at the root of a normal
automount point for a non-existent directory (or two, in this case)
isn't so bad (except for the annoying log spam), there are various types
of maps which take any rand
I'm seeing this too, and something about it is causing my system to
hang. Basically, when I come in the morning I can't do hardly anything,
including reboot. Investigation has shown that it's because any attempt
to read the /proc/mounts file causes a permanent hang on the process
(can't even kill
Looking into every mount point for .Trash directories is not a bug.
Looking is the only way to see if there are contents there that should
be displayed in the system trash can! (As Sebastien notes, the trash
can is shown as the union of all the per-filesystem trashcans, so the
only way to ensure a
I'm starting to believe we're looking at four different issues here
a) gvfsdtrash looking into every mountpoint for .Trash directories. This
should not be, as such, a problem.
b) gvfsdtrash's accumulating endlessly and keeping automounted NFS busy.
That is a bug.
c) gvfsdtrash not knowing that f
nobody denies that's an issue and it has been milestoned and is set as a
high priority ubuntu bug, the reason why it access all the partitions is
that the trash location is listing the different partition trash content
so it's looking on every partition to know if there is something to list
there
On Tue, 29 Apr 2008, Sebastien Bacher wrote:
>> this erroneous assumption is the bug
>
> it's not an assumption but it needs to look on the partition to know if
> there a directory there
>
It may need to look at THE partition (i.e., the partition on which a file
is actually being deleted, althou
> this erroneous assumption is the bug
it's not an assumption but it needs to look on the partition to know if
there a directory there
--
try to access a .Trash-$USER directory on autofs mounts
https://bugs.launchpad.net/bugs/210468
You received this bug notification because you are a member of
> This is happening from time to time; the bug was also in feisty and seems to
> be more likely to occurr in hardy.
Yes, it is.
> there is one such directory on every mount that's why it's trying to use those
That's simply not the case and this erroneous assumption is the bug. Perhaps
every moun
** Changed in: gvfs
Status: Unknown => New
--
try to access a .Trash-$USER directory on autofs mounts
https://bugs.launchpad.net/bugs/210468
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@
** Changed in: gvfs (Ubuntu)
Target: ubuntu-8.04 => ubuntu-8.04.1
--
try to access a .Trash-$USER directory on autofs mounts
https://bugs.launchpad.net/bugs/210468
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs ma
On a medium-sized installation with a few thousand automounter entries,
the resulting mount storm makes the system unusable. It is constantly
spawning new automount processes (almost like a fork bomb) and keeps
haldaemon at 99% CPU. Not sure how gvfs triggers this, a simple stat
/home/.Trash (where
there is one such directory on every mount that's why it's trying to use
those
--
try to access a .Trash-$USER directory on autofs mounts
https://bugs.launchpad.net/bugs/210468
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-b
I also have this problem. the nfs server log gets flooded by mount
request for .TrashX. in my case it's the home directories that is
auto mounted and nautilus/gvfs tries to create directories in /home that
is never going to work
Something needs to learn to detect that /home/user and /home is n
I tried again today, with gvfs 0.2.2svn20080403-0ubuntu1. I found that
the mount storm is currently pretty slow, but the gvfsd-trash processes
seem to be accumulating endlessly. After ~45 minutes, it has mounted
everything in our department, and I have over 3000 gvfsd-trash processes
(and 1.1GB co
so the mounts would be:
/dir/to/mount/ on /mountpoint/directoryToMountTo type nfs (opts)
ftp.example.com:/pub/myDir on /ftp/myDir type ftp (ro,soft)
--
try to access a .Trash-$USER directory on autofs mounts
https://bugs.launchpad.net/bugs/210468
You received this bug notification because you are
A very simple case would be something like this:
/etc/auto.master
**
/mountpoint /etc/auto.fileDescribingMount
/etc/auto.fileDescribingMount
**
directoryToMountTo -opts /dir/to/mount
Working example:
/etc/auto.master
could somebody describe an easy way to configure automount?
** Changed in: gvfs (Ubuntu)
Importance: Medium => High
--
try to access a .Trash-$USER directory on autofs mounts
https://bugs.launchpad.net/bugs/210468
You received this bug notification because you are a member of Ubuntu
Bugs, whi
Please also see duplicate bug #210586. gvfsd-trash continuously tries
to access the automount points (and keeps spawning and spawning,
although it does allow old processes to die before spawning more, so it
doesn't consume all available memory). The result is that, as soon as
someone logs in, the
Thanks for your bug report. This bug has been reported to the developers
of the software. You can track it and make comments here:
http://bugzilla.gnome.org/show_bug.cgi?id=525779
** Changed in: gvfs (Ubuntu)
Status: New => Triaged
** Changed in: gvfs (Ubuntu)
Importance: Low => Medium
41 matches
Mail list logo
