bugfindutils - Bugs: bug #14070, Spurious cycle detection with...

 
 

bug #14070: Spurious cycle detection with configure --with-fts and find -L

Submitter:  James Youngman <jay>
Submitted:  Tue 09 Aug 2005 09:23:00 PM UTC
   
 
Category:  find Severity:  3 - Normal
Item Group:  Wrong result Status:  Fixed
Privacy:  Public Assigned to:  jay
Originator Name:  Geoff Clare Open/Closed:  Closed
Release:  None Fixed Release:  4.2.25
* Mandatory Fields

Add a New Comment Rich Markup
   

Tue 09 Aug 2005 09:39:40 PM UTC, comment #3: 

The patch resolves the problem.

James Youngman <jay>
Group administrator
Tue 09 Aug 2005 09:25:35 PM UTC, comment #2: 

The attached patch from Jim Meyering proposes a solution to the problem.


James Youngman <jay>
Group administrator
Tue 09 Aug 2005 09:24:01 PM UTC, comment #1: 

Looks like a bug in the fts implementation:

I'm still investigating this problem, but I'm seeing some odd
behaviour with fts().  I have a directory layout like this:-

$ find find1 -ls
1299693    4 drwxr-xr-x   3 james    users        4096 Aug  8 20:33 find1
1299705    4 drwxr-xr-x   2 james    users        4096 Aug  8 20:33 find1/dir1
1299729    0 lrwxrwxrwx   1 james    users           4 Aug  8 20:33
+find1/symlink_to_dir1 -> dir1

If I invoke fts_open() with the FTS_LOGICAL flag and do not set
FTS_TIGHT_CYCLE_CHECK, then fts_read() returns FTS_DC in
ent->fts_info.  However, with the same directory layout FTS_DC is not set if FTS_TIGHT_CYCLE_CHECK is set.

fts_options                                     Result
FTS_NOSTAT|FTS_LOGICAL|FTS_TIGHT_CYCLE_CHECK    OK
FTS_NOSTAT|FTS_LOGICAL                          Loop (wrongly) detected
FTS_NOSTAT|FTS_PHYSICAL                         OK

This means that I suspect that there may be a problem with
cycle_check() in this case, as called from fts-cycle.c.  I have not fully investigated the problem yet, so I am not sure if there really is a problem.

I have noticed in particular that leave_dir() in fts-cycle.c does
nothing if FTS_TIGHT_CYCLE_CHECK is not set.  Perhaps that is related to this problem.

James Youngman <jay>
Group administrator
Tue 09 Aug 2005 09:23:00 PM UTC, original submission:  

The change you made to ftsfind.c has also caused a new problem with the
filesystem loop detection when following symlinks:

$ mkdir -p find1/dir1
$ touch find1/dir1/file1
$ ln -s dir1 find1/symlink_to_dir1
$ gfind-fts -L find1 -print
find1
find1/dir1
find1/dir1/file1
gfind-fts: Filesystem loop detected; find1/symlink_to_dir1 is part of thesame
+filesystem loop as find1/symlink_to_dir1.
$ find -L find1 -print
find1
find1/dir1
find1/dir1/file1
find1/symlink_to_dir1
find1/symlink_to_dir1/file1

(There is also a typo in the message: "thesame" -> "the same".)

Regards,
Geoff.

James Youngman <jay>
Group administrator

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #3332:  jm-patch added by jay (4KiB - application/octet-stream - Proposed fix from Jim Meyering)

 

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 5 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2005-09-03 jay Open/ClosedOpen Closed
    Fixed ReleaseNone 4.2.25
2005-08-09 jay StatusNone Fixed
2005-08-09 jay Attached File- Added jm-patch, #2793
2005-08-09 jay Carbon-Copy- Added -email is unavailable-

Back to the top

Powered by Savane 3.15-4cd8.
Corresponding source code