bugfindutils - Bugs: bug #27757, findutils and Time Machine, two...

 
 

bug #27757: findutils and Time Machine, two great tastes that don't go great together

Submitter:  Douglas Alan <nessus>
Submitted:  Mon 19 Oct 2009 07:53:33 PM UTC
   
 
Category:  updatedb Severity:  3 - Normal
Item Group:  Wrong result Status:  Wont Fix
Privacy:  Public Assigned to:  None
Originator Name:  Open/Closed:  Closed
Release:  None Fixed Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Thu 03 Dec 2009 11:28:53 PM UTC, comment #5: 

Thanks for the educational info!

Douglas Alan <nessus>
Thu 03 Dec 2009 11:17:27 PM UTC, comment #4: 

POSIX explicitly allows but does not require hard links to directories, and leaves it up to the implementation whether they will allow this behavior (and even on systems where it is allowed, POSIX also allows restricting the creation of directory hard-links to privileged users).  POSIX also requires that find detect any file system cycles (whether by directory hard links on systems where they are supported, or when using find -L on cyclical symlinks which can occur on all POSIX systems) rather than going into an infinite loop.

Newer findutils uses gnulib's enhanced fts() API, which is supposed to detect file system loops (due to directory hard links), and avoid infinite loops.  Your original test of findutils 4.2.20 used a hand-rolled iterator rather than fts(), so it may indeed be a bug that has been fixed in the meantime.

Eric Blake <ericb>
Group administrator
Thu 03 Dec 2009 07:02:34 PM UTC, comment #3: 

When I have a chance, I'll try to build findutils on my Mac and see if the problem still exists. Unfortunately, I'm extremely busy at a new job at the moment.

I can't imagine, however, that if nothing were done specifically to avoid Time Machine filesystems, that the problem could have gone away on its own. Running 'find' nightly on a filesystem that allows hard links to directories can never be a good thing. Not unless find has somehow been modified to be smart about such things. But hard links to directories have never been allowed in a Posix-compliant filesystem, have they?

Also, one typically wouldn't want to have the contents of a Time Machine filesystem cluttering up one's "locate" results anyway, even if it could be made to work.

Re the request for more information: I'm not sure what additional info you require. It's not easy to gather more information; I don't recall if there was even a comprehensible panic message in the log file. Instead of working from log files, I used the scientific method. I was able to deduce the cause of the problem due to the fact that the Mac would reliably crash every night in the wee hours of the morning, when the "locate" database was being updated. I hypothesized that "find" would use up an infinite amount of system resources if it were asked to infinitely recurse on a filesystem that allows directory loops. I turned off my Time Machine disk drive and the problem went away. I turned it back on  and the problem came back. I then went into the anacron config file that ran the nightly "locate" db find, and commented out the offending line. The problem went away.

Douglas Alan <nessus>
Sun 29 Nov 2009 03:29:30 PM UTC, comment #2: 

Nobody indicated they could investigate this and you didn't respond on the question of whether this problem exists in recent releases of findutils, so I'm going to mark the bug as obsolete.  Please reopen if you can reproduce the bug on findutils 4.5.x.   Thanks.

James Youngman <jay>
Group administrator
Wed 11 Nov 2009 11:33:54 PM UTC, comment #1: 

Findutils 4.2.20 was released on 2005-03-17.   A number of bugs have been fixed since then and certainly the code has changed almost beyond recognition in the ensuing four and a half years.

Please reproduce the bug on a recent version of findutils (for example 4.5.5, available from ftp://alpha.gnu.org).

If the problem is reproducible though, I will need more information than "this program will crash your Mac" to work on the problem - since I don't have a Mac.  I'm going to leave the bug unassigned for now in case one of the other contributors happens to have a Mac.

James Youngman <jay>
Group administrator
Mon 19 Oct 2009 07:53:33 PM UTC, original submission:  

I complained about this problem to fink-users, but I was told that this is an "upstream bug" and that I should report the bug here instead.

The findutils package adds an anacron job that runs a "find" over all your filesystems in the wee hours of the morning in order to build the database for "locate". Unfortunately, if you have installed findutils on Mac OS X and happen to have a Time Machine disk mounted, it seems that the "find" job run by anacron will likely crash your Mac.

I believe the reason for this is that Time Machine makes use of an interesting HFS+ capability wherein you can make hard links to directories. I'm guessing that Time Machine's extensive use of this feature causes "find" to rampantly eat up some sort of system resource, which, when exhausted, causes the system to crash.

Fink reports that version of findutils that I have installed is "4.2.20-7".

|>ouglas

Douglas Alan <nessus>

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by ericb (Posted a comment)
  • -email is unavailable- added by jay (Posted a comment)
  • -email is unavailable- added by nessus (Submitted the item)
  •  

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

    Date Changed by Updated Field Previous Value => Replaced by
    2009-11-29 jay Open/ClosedOpen Closed
        StatusNeed Info Wont Fix
    2009-11-11 jay StatusNone Need Info

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code