From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Sven Joachim Newsgroups: gmane.emacs.devel Subject: Re: unable to copy directory recursively to a vfat partition Date: Thu, 24 Jul 2008 16:05:25 +0200 Message-ID: <87ljzre5sq.fsf@gmx.de> References: <20080723185150.txs6e4gbr23ow0g4@webmail.mit.edu> <87zlo7zw5u.fsf@gmx.de> <87tzefzv2b.fsf@gmx.de> <87prp3a01h.fsf@stupidchicken.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1216908675 22717 80.91.229.12 (24 Jul 2008 14:11:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 24 Jul 2008 14:11:15 +0000 (UTC) Cc: emacs-devel@gnu.org To: Chong Yidong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jul 24 16:12:04 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KM1Xp-0004tl-3s for ged-emacs-devel@m.gmane.org; Thu, 24 Jul 2008 16:11:49 +0200 Original-Received: from localhost ([127.0.0.1]:54279 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KM1Wv-0006Wz-JQ for ged-emacs-devel@m.gmane.org; Thu, 24 Jul 2008 10:10:53 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KM1Wk-0006OQ-9R for emacs-devel@gnu.org; Thu, 24 Jul 2008 10:10:42 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KM1Wh-0006MN-Fy for emacs-devel@gnu.org; Thu, 24 Jul 2008 10:10:41 -0400 Original-Received: from [199.232.76.173] (port=53516 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KM1Wh-0006M8-Be for emacs-devel@gnu.org; Thu, 24 Jul 2008 10:10:39 -0400 Original-Received: from mail.gmx.net ([213.165.64.20]:42446) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1KM1Wh-0003sQ-6m for emacs-devel@gnu.org; Thu, 24 Jul 2008 10:10:39 -0400 Original-Received: (qmail invoked by alias); 24 Jul 2008 14:10:36 -0000 Original-Received: from p548641D2.dip.t-dialin.net (EHLO debian) [84.134.65.210] by mail.gmx.net (mp013) with SMTP; 24 Jul 2008 16:10:36 +0200 X-Authenticated: #28250155 X-Provags-ID: V01U2FsdGVkX19LfeRl66lLPYTw4XB/fEfLJHSrxhtkEoUQ13XRnF XU2lpxukMRXzrS In-Reply-To: <87prp3a01h.fsf@stupidchicken.com> (Chong Yidong's message of "Thu, 24 Jul 2008 09:23:22 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-Y-GMX-Trusted: 0 X-FuHaFi: 0.51 X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:101390 Archived-At: On 2008-07-24 15:23 +0200, Chong Yidong wrote: > Sven Joachim writes: > >> On 2008-07-24 07:30 +0200, Sven Joachim wrote: >> >>> I do have access to vfat, but I cannot reproduce the bug. IIRC there >>> was some change in Linux 2.6.25 that caused the chmod call to report >>> failure (it never works on vfat anyway, but that used to be silently >>> ignored). This change seems to have been reverted in the meantime, >>> though; I'm running 2.6.26 here. >> >> The change in 2.6.25 also broke rsync, as can be seen on >> https://bugzilla.redhat.com/show_bug.cgi?id=449080. I'll have a look at >> the problem when I get around to reboot with a 2.6.25 kernel. > > Does anyone know what the BSDs do? In other words, is reporting failure > for chmod simply "undefined behavior" that is up to the discretion of > the kernel (i.e., we need to be able to handle it), or is it simply a > Linux bug (i.e., we can probably get away with doing nothing)? I think we should avoid the first chown and create the directory with correct permissions from the start. Here is a patch for EMACS_22_BASE: 2008-07-24 Sven Joachim * dired-aux.el (dired-copy-file-recursive): Avoid calling set-file-modes when creating target directories. --8<---------------cut here---------------start------------->8--- --- dired-aux.el.~1.151.2.7.~ 2008-04-07 18:03:21.000000000 +0200 +++ dired-aux.el 2008-07-24 15:43:30.000000000 +0200 @@ -1180,9 +1180,12 @@ (if (file-exists-p to) (or top (dired-handle-overwrite to)) (condition-case err - (progn - (make-directory to) - (set-file-modes to #o700)) + (let ((default-mode (default-file-modes))) + (unwind-protect + (progn + (set-default-file-modes #o700) + (make-directory to)) + (set-default-file-modes default-mode))) (file-error (push (dired-make-relative from) dired-create-files-failures) --8<---------------cut here---------------end--------------->8--- If the directory permissions fail to be restored later, this will still be reported as an error, but I think it's correct to do that. Note that any program that recursively copies files and preserves permissions will have this problem on Linux 2.6.25 and vfat. Unless you mount the vfat filesystem with the `quiet' option, that is. Sven