Re: beagles eating my /var filesystem
"Brian J. Murrell" <[email protected]>
| Newsgroups | gmane.comp.gnome.dashboard.devel |
|---|---|
| Message-ID | <[email protected]> |
On Sun, 2007-12-09 at 11:41 -0500, D Bera wrote: > > The way the enable-deletions work is, while traversing the > directories, beagle keeps a note of all the directories that were > modified since last index. When indexing is done, it starts looking at > those directories (it prints a message "Checking xxx for deleted files > and directories") I don't see any such messages in my daily beagle crawl output. > So, if you sometimes run without --enable-deletion, No, I run with --enable-deletion every day and have been doing so since we last took a whack at this. > There might still be bugs in enable-deletion, as I said it never got > enough testing. One thing you could do for testing is, install some > doc package so that /usr/share/doc gets dirty again, That should happen almost every day as I upgrade to the latest hardy changes almost daily. > run with --enable-deletion and see if /usr/share/doc/bzr and its > recursive contents are removed. Hrm. /usr/share/doc/bzr is there and has contents and should be there as it's owned by the "bzr" package which I have installed. > Look for the "Checking xxx for deleted files and directories" message > near the end of the output messages. Nope. Don't see any such messages in my last successful crawl output (which I will send to you offline). > Unfortunately, all of the above is probably a red herring wrt the > original problem. Those extra entries cannot occupy that amount of > space. OK. > Its what I suspect a problem in Lucene and the workaround I added in > 0.3.0 might fix such problems. I will confirm once I get a chance to > look inside the segments file. I wonder when we will see 0.3.0 in hardy. b.