GNOME Bugzilla – Bug 48539
NFS mounts treated as "local" for show count, thumbnail, preview audio settings
Last modified: 2009-08-15 18:40:50 UTC
generic bug, but recreated on RedHat 6.2, and on Solaris 8 it was seen that while in the Speed Tradeoffs tab of the user Settings Menu, the user setting the Show Count of items in Folders to Local Folders Only has no effect... in other words it DOES NOT limit the showing of items to Local Folders only...the no of items in the folders is alowas displayed i checked on the users home area, other users home areas, remore automounted directories across NFS ------- Bug moved to this database by unknown@bugzilla.gnome.org 2001-09-09 21:18 ------- The original owner (pavel@eazel.com) of this bug does not have an account here. Reassigning to the default owner of the component, nautilus-maint@bugzilla.gnome.org.
Lets see if we can figure out how to fix this for 2.0.
Adding GNOME2 keyword.
I think perhaps NFS should be treated as local. It's basically a "fast" filesystem. But i'm not sure about this. Basically the gnome-vfs definition of is_local() is very vague and used in different ways. Sometimes it means "on a local harddrive", sometimes it means "fast device".
Alex: It's not necessarily particularly close or local; try it over cable modem to the office, for example. There is also at least one report that this is also true for AFS mounts- apparently nautilus will try to spider _all_ of AFS for trash cans in this case. Not sure if that is directly related to this or not, though, nor can I find the bug # ATM.
It appears this has the same root as 48536, even if the visible problem is slightly different, so marking duplicate. *** This bug has been marked as a duplicate of 48536 ***
Even though 48536 is fixed and is not reproducible, I still see this problem(count of items of nfs files) on my Solaris system.
Reopening, then. More is_local fun, Jody. :/
Dave: can you take a look at this?
This seems to work just fine for louie and me. I tested it both on linux and solaris 8. When the preference is Always, it shows counts, when it is Never, it doesn't show counts, and when it is Only if Local, it shows the count on local directories and not on nfs directories. Is this still a problem for you?
gnome_bugs: please have someone from your team take responsibility for this bug, since, AFAIK, peter is no longer with you.
hiya - sorry for the delay in replying... how does nautilus decide what is or is not an nfs dir? does naut read /etc/mnttab? if so what is the string it looks for? the reason I ask is that for some of our nfs dirs the "Local folders only" option works but for others it does not work. some of out dirs are in mnttab as "autofs" while others are in as "nfs"
adding cc
As Shane pointed out, for some of the mount dir it works fine, but for some it doesn't. For my automounted home dir it works fine. But for other automounted nfs directory it behaves weird. Say, If /a is automounted nfs dir: problem appears at /a problem doesn't appear for /a/b, problem appears at /a/b/c So, it is not very clear on what conditions it happens.
[Search for 'luis spamming' to catch every instance of this email.] In order to better track Sun's bugs for Sun and Ximian's internal use, I've added a temporary keyword to some bugs. I apologize for the spam, and for the use of an additional keyword, but this is the best way for Sun to track 'it's' bugs without interfering with the community's own triage and bug behavior. If you have any questions or objections, please drop me a note at louie@ximian.com or email bugmaster@gnome.org for more open discussion.
Kalpesh, Shane: is autofs always remote?
Luis, let us keep autofs/autmount apart for time being. Problem is present even on normal/standard nfs mount points too. I think I got the correct observation this time. The fix only fixes the directory where it is nfs mounted, any child directory there onwards still have the reported problem. To reproduce on Solaris I did: ============================== On system 'dftest1' do: a. add this line to /etc/dfs/dfstab share -F nfs -d "home dirs" /export/home b. /etc/init.d/nfs.server stop c. /etc/init.d/nfs.server start On system 'wipro' do: a. mkdir /tt b. mount -F nfs dftest1:/export/home /tt c. check the contents of /tt It shows: # cd /tt # ls -al total 34 drwxr-xr-x 7 root root 512 Jul 3 16:48 . drwxr-xr-x 105 root root 3072 Jul 3 17:56 .. drwxr-xr-x 2 root other 512 Jul 3 16:48 gnome-2.0 drwx------ 2 root root 8192 Jul 3 15:09 lost+found drwxr-xr-x 74 root other 1536 Jul 3 12:46 pkgs-03july drwxr-xr-x 4 root other 512 Jul 3 16:54 sanity drwxr-xr-x 2 root other 512 Jul 3 16:25 wipropkg-2.9-03jul # Invoke nautilus on 'wipro': Go to /tt you don't see number of items for any directory. Go to /tt/pkgs-03july you see number of items for each directory. Therefore, problem is partially fixed, i.e. it is fixed only at exact mount point but not if you go down inside it.
In the gnome-vfs source tree there is a program for testing the is_local code. Could you run gnome-vfs/test/test-info on a number of directories in nfs (the ones you aren't and aren't seeing the problem with), and see what the last line (File is/is not local) says please?
Created attachment 9804 [details] result of test-info, in both cases it says "File is not local".
I can't duplicate it on Nautilus with an nfs-mounted directory that has deep subdirectories. Also, test-info always seems to give the correct results on my box (Linux/Intel).
fstype.c seems to have some simple caching mechanism to avoid doing getmntent() every time. However, I don't know how it deals with changing mounts. Say you only have /mnt/foo mounted and it has device number N. Does the device number change if you umount /mnt/foo, mount /mnt/bar, then remount /mnt/foo?
I'm attaching a small patch that will create a ~/nautilus-directory-count-log.txt file. Could you please run nautilus with the patch, go to your NFS directories which exhibit the problem, and attach the log file output here? Thanks!
Created attachment 10112 [details] [review] Patch to create a diagnostics log file.
Kalpesh: can you please follow up on Federico's post ASAP? This smells a lot like a very complex problem, so the sooner we have information on how to duplicate the better.
*** Bug 89062 has been marked as a duplicate of this bug. ***
Re-titling to take the dupe into account.
This problem (count items) seems to be only Solaris specific. Attached is the debug/log output after adding patch. /data is the nfs mounted directory.
Created attachment 10184 [details] Diagnostic log file
Okay, this needs deeper digging. Kalpesh, the patch I sent you for Nautilus is no longer necessary, so please remove it from your copy. We now need a patch for gnome-vfs, which I will attach shortly. Could you please install the new patch for gnome-vfs, re-run nautilus and visit the problematic directories in turn? Then please attach the ~/gnome-vfs-is-local-log.txt file. Thanks!
Created attachment 10229 [details] [review] Diagnostics patch for gnome-vfs
Hi Federico, Before I update the diagnostic patch and do other stuff: I want to update you on my findings so far and then you let me whether I should go ahead with the diagnostic or not. 1. In gnome-vfs file file-method.c, under do_is_local() function there is a need to add "autofs" file system in addition to nfs and afs. 2. In file gnome-vfs fstype.c filesystem_type() function static char const *current_fstype = NULL; static dev_t current_dev; if (current_fstype != NULL) { if (fstype_known && statp->st_dev == current_dev) return current_fstype; /* Cached value. */ } There are two issues here: 2a. current_fstype doesn't seem to be actually static for data. i.e. when we enter here next time, the values are changed. and they are junk. It seems that it has to do with filesystem_type_uncached() where the pointer of 'type' gets assigned and then there is no guarantee that it will keep the same value or protect the data that eventually goes to current_fstype. Perhaps making fss struct static in filesystem_type_uncached() could resolve this problem. #ifdef FSTYPE_STATVFS /* SVR4. */ "static" struct statvfs fss; (in first round of testing it does resolve the problem). 2b. if (fstype_known && statp->st_dev == current_dev) return current_fstype; /* Cached value. */ If /data is nfs mounted dir. Then in Solaris it appears that statp->st_dev is same for /data/firstdir and /data/fisrtdir/seconddir etc.. So this will always suceed for child nfs dirs. But since current_fstype is set to junk value due to 2a, it returns as non-nfs dirs and therefore is shown as local dir. Please let me know if above sounds to be good reason for this bug. Also, let me know if you still want me to run diagnostic or a possible new patch.
You are right; the structs are on the stack and the strings are not copied. It looks like the latest GNU findutils fixes this problem, so I'll consult with the maintainer about re-licensing the code for the needs of gnome-vfs. I'm not sure if we need to add "autofs" to the cases in file-method.c - are autofs filesystems always nfs, or could you mount something like a local CD-ROM with it as well?
Should be fixed on CVS now. I still don't know about simply adding the "autofs" bit. Can't it mount local CD-ROMs as well, for example?
Yeah, lets leave 'autofs' for the moment. On Solaris, practically nobody uses autofs for cdrom, autofs by and large is used to mount nfs partitions. But, yes, technically it is possible to mount cdrom using autofs. Thanks for fixing this. (I see another issue, which I'll raise as separate bug :-) ).
so it's ok to close this then?
Yes, from my side.