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

 
 

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

Submitter:  None
Submitted:  Thu 21 Jul 2005 06:52:49 PM UTC
   
 
Category:  find Severity:  3 - Normal
Item Group:  Wrong result Status:  Wont Fix
Privacy:  Public Assigned to:  jay
Originator Name:  Bill Cole Originator Email:  -email is unavailable-
Open/Closed:  Closed Release:  4.2.23
Fixed Release:  4.2.24
* Mandatory Fields

Add a New Comment Rich Markup
   

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>
Group administrator
Mon 25 Jul 2005 05:46:46 PM UTC, comment #3: 

This divergence from traditional Unix behaviour is unfortunate.

James Youngman <jay>
Group administrator
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>
Group administrator
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 Files:
   
   
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

 

There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

Only logged-in users can vote.

 

Follow 6 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2005-09-03 jay Open/ClosedOpen Closed
2005-07-31 jay StatusNone Wont Fix
    Fixed ReleaseNone 4.2.24
2005-07-22 jay Assigned toNone jay
2005-07-21 None Attached File- Added trussout, #2730
    Carbon-Copy- Added william --DOT-- cole --AT-- gedas --DOT-- com

Back to the top

Powered by Savane 3.13-f8d8.
Corresponding source code