From: Musus U. <mu...@ve...> - 2007-07-24 18:53:52
|
Using ROX-Filer 2.6.1; I have 2 boxes here and my home dirs on one of them are exported via NFS to the others on the LAN: /home on 'thoth' is mounted as /mnt/nfs/thoth.home/ on my main machine. In my home dir. on 'thoth' I have a couple of symlinks: ScanImages -> .kde/share/apps/ScanImages WineDrive -> .wine/drive_c/ For some reason, the Filer is showing those with both the symlink and the mountpoint 'emblems'. Furthermore, the 'properties' dialogue thinks that they are mountpoints are shows the free/used info for the /home export. The symlinks appear just fine in the Filer running on 'thoth' itself, BTW. More generally, this seems to affect any symlink I create in that directory (but not its subdirectories) that points 'deeper' into it, IYSWIM. ln -s Foo FooLink ==> no problem ln -s Foo/Bar BarLink ==> shows as a mountpoint ln -s ../Foo FoosHome ==> shows as a mountpoint Out of curiosity, I checked: ln -s .. Parent ==> mountpoint (which it is ;) ln -s ln -s ../../documents Docs ==> No mountpoint (but actually, /mnt/nfs/documents (which is what /mnt/nfs/thoth.home/musus/../../documents/ points to) *is* a mountpoint on this box) Any ideas? TTFN, Adny -- Erst wenn die Wolken schlafengehn | Personal: ad...@ve... kann man uns am Himmel sehn | Techie: mu...@ve... wir haben Angst und sind allein | WWW: verelanthe.co.uk/musus/ Gott weiss ich will kein Engel sein! | UT: adn...@go... -- Rammstein / Engel |
From: Lucas H. <lu...@di...> - 2007-07-25 00:37:01
|
On Tue, 24 Jul 2007 19:53:47 +0100 Musus Umbra <mu...@ve...> wrote: > Using ROX-Filer 2.6.1; > > I have 2 boxes here and my home dirs on one of them are exported via > NFS to the others on the LAN: > /home on 'thoth' is mounted as /mnt/nfs/thoth.home/ on my main > machine. > My /home is an NFS mount on my desktops. This has happened to me in the past aswell. I initially thought it was a ROX problem, until I saw the same thing happen on a GNOME desktop. This indicates to me that it is most likely a bug in NFS. That said, you also might want to check the hardware in the the NFS server as at the same time this occurred I discovered I had some bad memory. -- Lucas Hazel |
From: Thomas L. <ta...@gm...> - 2007-07-25 10:23:46
|
On 7/24/07, Musus Umbra <mu...@ve...> wrote: > Using ROX-Filer 2.6.1; > > I have 2 boxes here and my home dirs on one of them are exported via NFS > to the others on the LAN: > /home on 'thoth' is mounted as /mnt/nfs/thoth.home/ on my main machine. > > In my home dir. on 'thoth' I have a couple of symlinks: > ScanImages -> .kde/share/apps/ScanImages > WineDrive -> .wine/drive_c/ > > For some reason, the Filer is showing those with both the symlink and > the mountpoint 'emblems'. Furthermore, the 'properties' dialogue > thinks that they are mountpoints are shows the free/used info for > the /home export. The logic the filer uses is this: - Stat $DIR and $DIR/.. - If the device is different, it's a mount point - If the inode is the same, it's a mount point (e.g. "/") e.g. to check if 'src' is a mount point: $ stat -c 'Device: %D Inode: %i' src src/.. Device: 802 Inode: 3375403 Device: 802 Inode: 3375312 Here, the parent is a different inode on the same device => 'src' is not a mount point. -- Dr Thomas Leonard http://rox.sourceforge.net GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 |
From: Lucas H. <lu...@di...> - 2007-07-25 12:38:22
|
On Wed, 25 Jul 2007 11:23:44 +0100 "Thomas Leonard" <ta...@gm...> wrote: > $ stat -c 'Device: %D Inode: %i' src src/.. > Device: 802 Inode: 3375403 > Device: 802 Inode: 3375312 This again made me think it is a problem with NFS rather than ROX. Seeing as the stat function call is reporting incorrect numbers, made me think of rpc.statd. After some investigation I noticed that rpc.statd was not running on my file server (FreeBSD). I've enabled rpc.statd, restarted the file server and clients. It's all back to normal again, but we'll see for how long.... -- Lucas Hazel <lu...@di...> ================================================= "Clothes make the man. Naked men are rarely taken seriously, or given employment." ================================================= |
From: Lucas H. <lu...@di...> - 2007-07-25 12:13:15
|
On Wed, 25 Jul 2007 11:23:44 +0100 "Thomas Leonard" <ta...@gm...> wrote: > On 7/24/07, Musus Umbra <mu...@ve...> wrote: > > Using ROX-Filer 2.6.1; > > > > I have 2 boxes here and my home dirs on one of them are exported > > via NFS to the others on the LAN: > > /home on 'thoth' is mounted as /mnt/nfs/thoth.home/ on my main > > machine. > > > > In my home dir. on 'thoth' I have a couple of symlinks: > > ScanImages -> .kde/share/apps/ScanImages > > WineDrive -> .wine/drive_c/ > > > > For some reason, the Filer is showing those with both the symlink > > and the mountpoint 'emblems'. Furthermore, the 'properties' > > dialogue thinks that they are mountpoints are shows the free/used > > info for the /home export. > > The logic the filer uses is this: > > - Stat $DIR and $DIR/.. > - If the device is different, it's a mount point > - If the inode is the same, it's a mount point (e.g. "/") > > e.g. to check if 'src' is a mount point: > > $ stat -c 'Device: %D Inode: %i' src src/.. > Device: 802 Inode: 3375403 > Device: 802 Inode: 3375312 > > Here, the parent is a different inode on the same device => 'src' is > not a mount point. > > As if by divine providence, it has started happening to me again aswell. http://nipul.die.net.au/nfsbug.jpg -- Lucas Hazel <lu...@di...> ================================================= "Clothes make the man. Naked men are rarely taken seriously, or given employment." ================================================= |
From: Musus U. <mu...@ve...> - 2007-07-25 13:05:27
|
On Wednesday 25 Jul 2007, Lucas Hazel wrote: > As if by divine providence, it has started happening to me again > aswell. > http://nipul.die.net.au/nfsbug.jpg (Re. Lucas' other post: rpc.statd are running fine here, so that's not my problem...) Same 'stat' behaviour here, as well; eg. $ stat -c 'Device: %D Inode: %i' WineDrive WineDrive/.. Device: 1a Inode: 9666567 Device: 1a Inode: 24216416 So I thought I'd see what the Filer was seeing for the values... but when I rebuilt it I found that it wasn't even checking those symlinks and, indeed, they appear just fine. Of course, since I last built the filer, all sorts of fun things have changed as a result of routine updates (gcc and glibc, to name but two 'small' players in the saga ;)... Ah well: fresh build of the filer installed; problem solved ;) TTFN, Adny -- Erst wenn die Wolken schlafengehn | Personal: ad...@ve... kann man uns am Himmel sehn | Techie: mu...@ve... wir haben Angst und sind allein | WWW: verelanthe.co.uk/musus/ Gott weiss ich will kein Engel sein! | UT: adn...@go... -- Rammstein / Engel |
From: Stephen W. <Ste...@ul...> - 2007-07-26 13:34:26
|
rox...@li... wrote: > So I thought I'd see what the Filer was seeing for the values... but > when I rebuilt it I found that it wasn't even checking those symlinks > and, indeed, they appear just fine. I've had a quick look after it happened to me. It appears there is a bug i= n diritem_restat() when handling relative symbolic links as mount_is_mounte= d() gets passed a relative path, in my case "../..". It then stats "../../= .." as the parent which, when the filer is running from my home directory i= s a different device. If you've restarted the filer, it may be running from a different directory= and the relative paths may be ending up elsewhere. |
From: Musus U. <mu...@ve...> - 2007-07-26 14:35:27
|
On Thursday 26 Jul 2007, Stephen Watson wrote: > rox...@li... wrote: > > So I thought I'd see what the Filer was seeing for the values... > > but when I rebuilt it I found that it wasn't even checking those > > symlinks and, indeed, they appear just fine. > I've had a quick look after it happened to me. It appears there is a > bug in diritem_restat() when handling relative symbolic links as > mount_is_mounted() gets passed a relative path, in my case "../..". > It then stats "../../.." as the parent which, when the filer is > running from my home directory is a different device. Ah :) > If you've restarted the filer, it may be running from a different > directory and the relative paths may be ending up elsewhere. Indeed - that seems to be the case here... and, of course, my freshly rebuilt & installed filer is now (after having logged back in) showing exactly the same behaviour as before :) TTFN, Adny -- Erst wenn die Wolken schlafengehn | Personal: ad...@ve... kann man uns am Himmel sehn | Techie: mu...@ve... wir haben Angst und sind allein | WWW: verelanthe.co.uk/musus/ Gott weiss ich will kein Engel sein! | UT: adn...@go... -- Rammstein / Engel |
From: Stephen W. <st...@ke...> - 2007-07-26 18:21:10
|
Stephen Watson <Ste...@ul...> wrote: > rox...@li... wrote: > > So I thought I'd see what the Filer was seeing for the values... but > > when I rebuilt it I found that it wasn't even checking those symlinks > > and, indeed, they appear just fine. > > I've had a quick look after it happened to me. It appears there is a bug in diritem_restat() when handling relative symbolic links as mount_is_mounted() gets passed a relative path, in my case "../..". It then stats "../../.." as the parent which, when the filer is running from my home directory is a different device. > > If you've restarted the filer, it may be running from a different directory and the relative paths may be ending up elsewhere. Use pathdup() in diritem_restart(), not readlink_dup(), to ensure that we get the full pathname and not a path relative to the filer's working directory (Stephen Watson). diff --git a/ROX-Filer/src/diritem.c b/ROX-Filer/src/diritem.c index 869cff3..7a24391 100644 --- a/ROX-Filer/src/diritem.c +++ b/ROX-Filer/src/diritem.c @@ -118,7 +118,7 @@ void diritem_restat(const guchar *path, item->flags |= ITEM_FLAG_SYMLINK; - target_path = readlink_dup(path); + target_path = pathdup(path); } else { -- Stephen Watson http://www.kerofin.demon.co.uk/ If you read this on a mailing list, send any reply back to the list and not to me. Not even CC. "Bad dog!" "Affirmative!" |
From: Musus U. <mu...@ve...> - 2007-07-26 20:39:09
|
On Thursday 26 Jul 2007, Stephen Watson wrote: > Stephen Watson <Ste...@ul...> wrote: <snip> > Use pathdup() in diritem_restart(), not readlink_dup(), to ensure > that we get the full pathname and not a path relative to the filer's > working directory (Stephen Watson). Thanks - problem really solved now :) TTFN, Adny -- Erst wenn die Wolken schlafengehn | Personal: ad...@ve... kann man uns am Himmel sehn | Techie: mu...@ve... wir haben Angst und sind allein | WWW: verelanthe.co.uk/musus/ Gott weiss ich will kein Engel sein! | UT: adn...@go... -- Rammstein / Engel |