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
Priority:  5 - 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

Post a Comment

Add a New Comment Rich Markup
   

Discussion

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

 

Attached Files

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

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

Attach Files:
   
   
Comment:
   

 

Dependencies

This item does not depend on any other items.

No items depend on this one.

 

Mail Notification Carbon-Copy List

 

Votes

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.

 

History

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.16-ed84.
Corresponding source code