From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Pete Gillin Newsgroups: gmane.emacs.help Subject: Execute permission on Windows XP emacs 22.1 Date: Mon, 9 Jul 2007 10:14:27 +0100 Message-ID: <20070709091427.GA14208@void.printf.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1183972499 30022 80.91.229.12 (9 Jul 2007 09:14:59 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 9 Jul 2007 09:14:59 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Mon Jul 09 11:14:57 2007 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1I7pKb-0001wl-6G for geh-help-gnu-emacs@m.gmane.org; Mon, 09 Jul 2007 11:14:57 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I7pKa-00071O-M1 for geh-help-gnu-emacs@m.gmane.org; Mon, 09 Jul 2007 05:14:56 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1I7pKJ-00071A-6z for help-gnu-emacs@gnu.org; Mon, 09 Jul 2007 05:14:39 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1I7pKH-00070y-Nv for help-gnu-emacs@gnu.org; Mon, 09 Jul 2007 05:14:38 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I7pKH-00070v-FY for help-gnu-emacs@gnu.org; Mon, 09 Jul 2007 05:14:37 -0400 Original-Received: from void.printf.net ([217.147.94.159]) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1I7pKG-0006ev-NE for help-gnu-emacs@gnu.org; Mon, 09 Jul 2007 05:14:37 -0400 Original-Received: from pete by void.printf.net with local (Exim 4.50) id 1I7pK7-0003xA-O2 for help-gnu-emacs@gnu.org; Mon, 09 Jul 2007 10:14:27 +0100 Content-Disposition: inline User-Agent: Mutt/1.5.9i X-detected-kernel: Genre and OS details not recognized. X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:45549 Archived-At: OS: Windows XP Pro / SP2 Emacs: This is GNU Emacs 22.1.1 (i386-mingw-nt5.1.2600) of 2007-06-02 on RELEASE Can anyone explain to me why emacs refuses to create files without "Read and Execute" permission set (for the creating user)? I tried things like the following in my startup file, to set the value and allow me to inspect it immediately after setting (by looking at the variable) and at runtime (by running the insert function). (set-default-file-modes ?\644) (setq my-default-file-modes (number-to-string (default-file-modes))) (defun insert-default-file-modes () "inserts current value of default-file-modes" (interactive) (insert (number-to-string (default-file-modes)))) Both ways of checking the value agree, and suggest that the value I have tried to set has been immediately ORed with 177 (octal). In the above case, when I've tried to set 644, the value actually set is 777. And looking at the file properties confirms that "Read and Execute" is set for the creating user whatever modes I've asked for. Which is unhelpful, frankly. Thanks, Pete. P.S. I know that the normal behaviour on Windows is to make everything executable by default --- but I don't see why emacs should insist on doing this when I've explicitly asked it not to. The reason this bothers me (if you're curious) is that I'm using the Subversion version control system (the cygwin client) and when I add a file which has "Read and Execute" locally, it automatically sets the repository property svn:executable and so (if I forget to unset it) we get the executable bit set on all working copies (including linux where it matters more). P.P.S. The behaviour seemed to be even odder on emacs 21.3, but I didn't investigate thoroughly.