From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [gmane.emacs.bugs] Emacs fails to start properly if the current working directory is on a vfat or ntfs filesystem Date: Mon, 25 Feb 2008 23:53:24 -0500 Message-ID: References: <877igvl4dn.fsf@stupidchicken.com> <47C180F9.2060901@gnu.org> <47C2014A.4090702@gnu.org> <47C35614.6020407@gnu.org> <87pruk9ygb.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 1204001630 5063 80.91.229.12 (26 Feb 2008 04:53:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 26 Feb 2008 04:53:50 +0000 (UTC) Cc: eliz@gnu.org, emacs-devel@gnu.org, rms@gnu.org, Jason Rumney To: Chong Yidong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 26 05:54:11 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 1JTrpT-0001pI-AK for ged-emacs-devel@m.gmane.org; Tue, 26 Feb 2008 05:54:11 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JTrox-0002ei-EV for ged-emacs-devel@m.gmane.org; Mon, 25 Feb 2008 23:53:39 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JTrou-0002eT-En for emacs-devel@gnu.org; Mon, 25 Feb 2008 23:53:36 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JTrot-0002eH-UB for emacs-devel@gnu.org; Mon, 25 Feb 2008 23:53:36 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JTrot-0002eE-RN for emacs-devel@gnu.org; Mon, 25 Feb 2008 23:53:35 -0500 Original-Received: from ironport2-out.pppoe.ca ([206.248.154.182]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JTroj-0007nM-CA; Mon, 25 Feb 2008 23:53:25 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAIMqw0dMCpz5Wmdsb2JhbACQVAEgm2R/ X-IronPort-AV: E=Sophos;i="4.25,405,1199682000"; d="scan'208";a="15054154" Original-Received: from smtp.pppoe.ca ([65.39.196.238]) by ironport2-out.pppoe.ca with ESMTP; 25 Feb 2008 23:53:24 -0500 Original-Received: from pastel.home ([76.10.156.249]) by smtp.pppoe.ca (Internet Mail Server v1.0) with ESMTP id GGB61324; Mon, 25 Feb 2008 23:53:24 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 364927FA7; Mon, 25 Feb 2008 23:53:24 -0500 (EST) In-Reply-To: <87pruk9ygb.fsf@stupidchicken.com> (Chong Yidong's message of "Mon, 25 Feb 2008 22:41:08 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) 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:90482 Archived-At: >>> Here is a patch against EMACS_22_BASE. >> >> I'd rather use a less arbitrary scheme. E.g. >> - only accept unchanged safe chars (rather than rule out >> dangerous ones), e.g. [:alnum:] and maybe a couple more. >> - everything else encoded following quoted-printable. >> >> Of course, QP applies to bytes, not to chars, which also points to >> a potential problem with [:alnum:] since it includes multibyte chars >> which may also be rejected, but I think that would be safe enough for >> a start. > What do you mean by quoted-printable? QP uses "=NN" where NN is the hexadecimal code of the encoded byte. Using "%NN" instead would work as well, of course. Or maybe "%NNNN%" so as to accept arbitrary chars rather than just bytes. > I was thinking that we could instead change all unsafe chars into the > same character, e.g. an underscore. I don't think there is much risk > of name clashing (in the first place, we already use make-temp-file to > generate a unique filename.) That would be simpler, indeed. But I cannot assess the risk and the current code goes through some extra trouble to avoid name clashes, so it seems safer to follow the original code's intention (and implicit risk assessment). Stefan