Ah, herewith the last few lines: open("..", O_RDONLY) = 5 fstat64(5, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 fchdir(5) = 0 close(5) = 0 open("mike", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = -1 ENOENT (No such file or directory) --- SIGPIPE (Broken pipe) --- +++ killed by SIGPIPE +++
And I believe I've found the problem! I'm running something called SHFS (http://shfs.sourceforge.net/) which is able to mount a file system across SSH. In /home/mike I have a symlink to /mnt/mike which is mounting /home/mike on a friends computer. I tried to cd /mnt/mike and I got a broken pipe - it appears that the ssh mount died and wasn't elegantly handling the chdir into a broken mount point. I'm going to give the maintainer of SHFS a buzz and let him know about it. Two questions... 1) How can I exclude /mnt from updatedb (or is it already) 2) The problem appeared to be following the symlink - can I tell updatedb to not follow symlinks; I don't see why it should as it should index the target file anyway... Thank you so much for your assistance Brian and Jon. -----Original Message----- From: Brian Ashe [mailto:[EMAIL PROTECTED] Sent: 18 June 2003 20:36 To: [EMAIL PROTECTED] Subject: Re[2]: updatedb problem: last try!! Hello michael, Wednesday, June 18, 2003, 12:49:17 PM, you textually orated: mbwc> Thanks for the recommendation, Brian - but I'm not sure that is mbwc> the case. mbwc> Filesystem Size Used Avail Use% Mounted on mbwc> /dev/hda1 9.8G 6.3G 3.0G 68% / mbwc> /dev/hda2 65G 46G 15G 75% /home mbwc> none 124M 0 124M 0% /dev/shm mbwc> I can also cp /var/lib/slocate/slocate.db mbwc> /var/lib/slocate/slocate.db2/3/4/5/6 etc... Until I'm blue in the mbwc> face. mbwc> One thing I was wondering, I was speaking to a friend about this mbwc> and he suggested removing my slocate database my deleting mbwc> slocate.db - but in his case it was in a different location. I was mbwc> wondering if perhaps the last action being taken is slocate is mbwc> trying to move a file from the wrong location to the wrong mbwc> location - although the fact that it creates the .tmp file in the mbwc> correct place doubts this assumption; it's the only thing I can mbwc> think of right now! Try stracing it and perhaps only do a small part of the drive by calling slocate directly... strace slocate -U /usr/share/icons -o ~/test_sl.db ...and see if A) it completes without error and B) what the output of strace is if it fails. If you don't mind spending the time, you could also just do "strace updatedb". You should only need the last ~20 lines or so of the output. Have fun, -- _________________________________________________________________ Brian Ashe CTO [EMAIL PROTECTED] Dee-Web Software Services, LLC. http://www.dee-web.com/ ----------------------------------------------------------------- -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://www.redhat.com/mailman/listinfo/redhat-list