bugfindutils - Bugs: bug #13880, find fails to descend into...

 
 

bug #13880: find fails to descend into directories on HSFS filesystems on Solaris 9

Submitted by:  None
Submitted on:  Thu 21 Jul 2005 06:52:49 PM UTC  
 
Category: findSeverity: 3 - Normal
Item Group: Wrong resultStatus: Wont Fix
Privacy: PublicAssigned to: James Youngman <jay>
Originator Name: Bill ColeOriginator Email: -unavailable-
Open/Closed: ClosedRelease: 4.2.23
Fixed Release: 4.2.24

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Sun 31 Jul 2005 09:28:58 PM UTC, comment #4:

If you have a system with filesystems which depart from the Unix behaviour in this way you can work around the problem either by using -noleaf for the affected filesystems or by configuring findutils with the option --disable-leaf-optimisation.

James Youngman <jay>
Project AdministratorIn charge of this item.
Mon 25 Jul 2005 05:46:46 PM UTC, comment #3:

This divergence from traditional Unix behaviour is unfortunate.

James Youngman <jay>
Project AdministratorIn charge of this item.
Mon 25 Jul 2005 04:26:17 PM UTC, comment #2:

I believe option #1 is the operative one. HSFS is High Sierra/ISO-9660, i.e. read-only CD-ROM's, DVD's, and ISO images. All of the dozen CD's and images from multiple sources that I've looked at on Solaris 8 and 9 systems show 2 links for . at the top level of the mounted HSFS filesystem.

Anonymous
Fri 22 Jul 2005 08:12:58 PM UTC, comment #1:

The problem is that the hard link count for /mnt/solaris10/s0 is wrong. Its hard link count is 2. That indicates that the directory has no subdirectories (the two hard links being . and ..).

I think that this means one of the following is true:

1. Your Solaris filesystem fails to follow traditional Unix semantics
2. Your filesystem is corrupt (i.e. the link count is not supposed to be 2)

I'm quite surprosed by this - the link count is normally reliable, so perhaps something less obvious is going on. You can work around the problem with -noleaf but I would prefer to understand why the Solaris kernel is behaving in this way.

I think the door_info() calls are not related to the problem - it's probably the underlying implementation of getpwuid() and getgrgid().

James Youngman <jay>
Project AdministratorIn charge of this item.
Thu 21 Jul 2005 06:52:49 PM UTC, original submission:

This problem is reproducible with GNU find from the Sunfreeware package of 6/23/2002 (claims to be version 4.1) from the Sun Solaris 9 software companion CD (claims to be version 4.1.20 of 2/6/2004) and version 4.2.23 freshly built today.

The following example shows what I get when looking for every file on a 2.8GB filesystem which in fact contains tens of thousands of files:

root@sysadm13:findutils-4.2.23# truss find/find /mnt/solaris10/s0 -ls 2>trussout
93696 2 dr-xr-xr-x 2 root sys 2048 Jan 23 05:24 /mnt/solaris10/s0
93703 1 -r--r--r-- 1 root root 93 Jan 6 2005 /mnt/solaris10/s0/.cdtoc
2741952 2 drwxr-xr-x 5 root other 2048 Jan 23 05:24 /mnt/solaris10/s0/.install
93710 0 lrwxrwxrwx 1 root other 33 Jan 23 05:22 /mnt/solaris10/s0/.install_config -> ./Solaris_10/Misc/.install_config
93716 1 -r--r--r-- 1 root root 462 Jan 6 2005 /mnt/solaris10/s0/.slicemapfile
93720 1 -r--r--r-- 1 root root 21 Jan 6 2005 /mnt/solaris10/s0/.volume.inf
93724 1 -r--r--r-- 1 root other 23 Jan 22 22:21 /mnt/solaris10/s0/.volume.inf.2
93728 1 -r--r--r-- 1 root other 23 Jan 22 22:21 /mnt/solaris10/s0/.volume.inf.3
93732 1 -r--r--r-- 1 root other 23 Jan 22 22:22 /mnt/solaris10/s0/.volume.inf.4
93737 7 -r--r--r-- 1 root root 6308 Jan 6 2005 /mnt/solaris10/s0/Copyright
93740 449 -r--r--r-- 1 root root 459760 Jan 6 2005 /mnt/solaris10/s0/JDS-THIRDPARTYLICENSEREADME
93760 2 drwxr-xr-x 8 root root 2048 Jan 23 05:24 /mnt/solaris10/s0/Solaris_10
93749 1 -rwxr-xr-x 1 root other 257 Jan 22 22:22 /mnt/solaris10/s0/installer
root@sysadm13:findutils-4.2.23#

The truss output from that run is attached. It shows no attempt to chdir into either of the two directories found under the starting point.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

Attached Files
file #3259:  trussout added by None (7KiB - application/octet-stream - truss output from the example run.)

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

Do you think this task is very important?
If so, you can click here to add your encouragement to it.
This task has 0 encouragements so far.

Only logged-in users can vote.

 

Please enter the title of George Orwell's famous dystopian book (it's a date):

 

 

Follow 6 latest changes.

Date Changed By Updated Field Previous Value => Replaced By
Sat 03 Sep 2005 11:42:31 AM UTCjayOpen/ClosedOpen=>Closed
Sun 31 Jul 2005 09:28:58 PM UTCjayStatusNone=>Wont Fix
  Fixed ReleaseNone=>4.2.24
Fri 22 Jul 2005 08:12:58 PM UTCjayAssigned toNone=>jay
Thu 21 Jul 2005 06:52:50 PM UTCNoneAttached File-=>Added trussout, #2730
  Carbon-Copy-=>Added william --DOT-- cole --AT-- gedas --DOT-- com

Back to the top


Powered by Savane 3.1-cleanup1