GNOME Bugzilla – Bug 417880
libbeagle does not find beagle directory for nfs mounted home dir
Last modified: 2007-08-30 11:21:41 UTC
Please describe the problem: Hello, I want to refer to a bugreport at KDE. Nothing has changed the situation mentioned [1] yet. [1] http://bugs.kde.org/show_bug.cgi?id=142637 Steps to reproduce: 1. Install Kerry (http://en.opensuse.org/Kerry) 2. Move .beagle directory to some other place and create a symbolic link to it - pointing from ~ to the new location 3. Start Kerry and start the beagle daemon. Kerry won't be able to recognize any running beagle daemon. Actual results: Kerry is not able to search the beagle database since it is not able to detect the running beagle daemon. Expected results: Kerry should be able to work with the symlinked .beagle directory, detect the running beagle daemon and return search results. Does this happen every time? Yes. Other information:
I believe this is already fixed in SVN?
Dont know. I fixed the BEAGLE_STORAGE for libbeagle in svn months ago but I dont know the status of symlinked .beagle directory.
I tested with a symlinked .beagle directory and svn. Its working.
Well it's working, but not for Kerry. This means libbeagle might still be broken. I've just installed libbeagle from svn which did not solve this problem. Maybe still a problem with beagle_util_daemon_is_running().
I checked with the libbeagle example program in libbeagle/examples/*.c I will check again in a few days, but you are using the svn trunk (and not the bugfix branch) - right ?
(In reply to comment #5) > I checked with the libbeagle example program in libbeagle/examples/*.c > I will check again in a few days, but you are using the svn trunk (and not the > bugfix branch) - right ? I used this to checkout: svn checkout http://svn.gnome.org/svn/beagle/trunk/libbeagle
I am unable to reproduce it. [debajyoti@dbera ~]$ stat .beagle File: `.beagle' -> `.foo' Size: 4 Blocks: 0 IO Block: 4096 symbolic link Device: 1609h/5641d Inode: 29442888 Links: 1 Access: (0777/lrwxrwxrwx) Uid: ( 502/debajyoti) Gid: ( 502/debajyoti) and then kerry works! (BEAGLE_HOME and BEAGLE_STORAGE is not set). [debajyoti@dbera src]$ ./kerry ScimInputContextPlugin() ~ScimInputContextPlugin() ScimInputContextPlugin() [debajyoti@dbera src]$ kerry: Creating client with id:661209457 kerry: searchProgramList kerry: searchBookmars kerry: searchAddressBook kerry: starting BeagleSearch kerry: ---------- finished kerry: Finished query ... Do you have your home directory on nfs or smb ?
(In reply to comment #7) > I am unable to reproduce it. > > [debajyoti@dbera ~]$ stat .beagle > File: `.beagle' -> `.foo' > Size: 4 Blocks: 0 IO Block: 4096 symbolic link > Device: 1609h/5641d Inode: 29442888 Links: 1 > Access: (0777/lrwxrwxrwx) Uid: ( 502/debajyoti) Gid: ( 502/debajyoti) > > and then kerry works! (BEAGLE_HOME and BEAGLE_STORAGE is not set). > > [debajyoti@dbera src]$ ./kerry > ScimInputContextPlugin() > ~ScimInputContextPlugin() > ScimInputContextPlugin() > [debajyoti@dbera src]$ kerry: Creating client with id:661209457 > kerry: searchProgramList > kerry: searchBookmars > kerry: searchAddressBook > kerry: starting BeagleSearch > kerry: ---------- finished > kerry: Finished query ... > > Do you have your home directory on nfs or smb ? Yes, my home directory is on nfs. mount returns for my home: data:/home/work on /home/work type nfs (rw,nosuid,nodev,hard,intr,rsize=8192,wsize=8192,rsize=8192,wsize=8192,addr=xxx.xxx.xxx.xxx)
> > Do you have your home directory on nfs or smb ? > Yes, my home directory is on nfs. Ah. Beagle behaves a bit differently when .beagle is on NFS mounted filesystem. I dont really know the exact steps that happen, roughly it is copied to a temporarary directory on a local filesystem and then the contents of .beagle are kept in sync. This is to ensure fast access to .beagle contents. Joe, how does BeagleClient-C# get the correct location for .beagle for NFS filesystems ?
Created attachment 85409 [details] [review] correct determination of beagle storage directory Can you apply the patch and see if it makes any difference ? Libbeagle was using a slightly different approach for nfs mounted .beagle, the patch would make it follow the same steps as our C# api.
(In reply to comment #10) > Created an attachment (id=85409) [edit] > correct determination of beagle storage directory > > Can you apply the patch and see if it makes any difference ? Libbeagle was > using a slightly different approach for nfs mounted .beagle, the patch would > make it follow the same steps as our C# api. I applied the patch but unfortunately it does not solve my problem. What I did after I had installed the patched libbeagle: - removed .beagle in my home directory. - started kerry and configured stuff -> ~.beagle was created - moved the newly created ~.beagle to /local/.beagle - created a symlink from ~.beagle to /local/.beagle - from within kerry I started the beagle-daemon - beagle-daemon is running but kerry does not recognise it
Created attachment 85463 [details] [review] stupid mistake in previous patch, fix that Can you do it the other way round ? i.e. - apply the patch - removed .beagle in home directory - started beagled (manually or from kerry) - quit kerry - move .beagle to somewhere else and create the symlink - start kerry and beagled (from kerry or manually)
(In reply to comment #12) > Created an attachment (id=85463) [edit] > stupid mistake in previous patch, fix that This fixed it, thank you. But you might want to fix the patch: you changed it to beagle_storage instead of beagle_storage_dir.
> This fixed it, thank you. But you might want to fix the patch: you changed it > to beagle_storage instead of beagle_storage_dir. Oho, must have forgotten to build before attaching patch. I presume you changed beagle_storage to beagle_storage_dir and everything (builds and) works fine. I will commit the patch.
Checked this is. r3609.
Unfortunately the bug still exists in version 0.2.17 to which I upgraded recently. I fixed it by adding the patch (slightly modified) again. I checked the sources from version 0.2.18 and the lines look alike. I afraid this happens with 0.2.18 too.
> Unfortunately the bug still exists in version 0.2.17 to which I upgraded > recently. I fixed it by adding the patch (slightly modified) again. I checked > the sources from version 0.2.18 and the lines look alike. I afraid this happens > with 0.2.18 too. Oops you are right ... the patch was not merged to 0.2.17/18. I merged (with 3890, 3860, 3861, 3863) 3609 in r3921 in the branch used to release 0.2.17/18. Its too late for 0.2.18. In case another 0.2.* release is made, it will have the problem fixed.