X-Spam-Check-By: sourceware.org Date: Mon, 16 Oct 2006 15:46:46 +0200 From: Corinna Vinschen To: cygwin@cygwin.com Subject: Re: Permission to read anything from ls, cp, and find? Message-ID: <20061016134646.GW8323@calimero.vinschen.de> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <20061012202458.GA24871@panix.com> <20061016131417.GV8323@calimero.vinschen.de> <4533875B.2020807@byu.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4533875B.2020807@byu.net> User-Agent: Mutt/1.4.2i Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Delivered-To: mailing list cygwin@cygwin.com On Oct 16 07:21, Eric Blake wrote: > According to Corinna Vinschen on 10/16/2006 7:14 AM: > > for instance, find(1) traverses directory trees by chdir'ing into > > directories before listing them. So even with this patch, find(1) is > > still not a good candidate for backing up directory trees in a situation > > as you describe above. tar(1) doesn't seem to have this problem, > > though. > > Which version of find? find 4.3.0 switched over to gnulib's fts > implementation, which, if openat() and friends were to be implemented, is It's with find 4.3.0. It just doesn't traverse into a directory which it has no permissions for. Since reading the directory works usually, I concluded that the failing chdir (see an strace) is the culprit. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/