From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: joakim@verona.se Newsgroups: gmane.emacs.devel Subject: Re: remember(-diary).el Date: Thu, 22 Nov 2007 10:44:06 +0100 Message-ID: References: <4743DD30.4010504@gmx.at> <4743EFE7.7080907@gmx.at> <87myt7aejq.fsf@catnip.gol.com> <4745446E.6010009@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1195725373 31906 80.91.229.12 (22 Nov 2007 09:56:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 22 Nov 2007 09:56:13 +0000 (UTC) To: emacs-devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 22 10:56:21 2007 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 1Iv8nE-0006n8-7h for ged-emacs-devel@m.gmane.org; Thu, 22 Nov 2007 10:56:20 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Iv8mz-0002to-OM for ged-emacs-devel@m.gmane.org; Thu, 22 Nov 2007 04:56:05 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Iv8mr-0002qs-Vv for emacs-devel@gnu.org; Thu, 22 Nov 2007 04:55:58 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Iv8mp-0002nL-Hy for emacs-devel@gnu.org; Thu, 22 Nov 2007 04:55:56 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Iv8mo-0002ms-UY for emacs-devel@gnu.org; Thu, 22 Nov 2007 04:55:55 -0500 Original-Received: from proxy2.bredband.net ([195.54.101.72]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Iv8mo-0000Px-62 for emacs-devel@gnu.org; Thu, 22 Nov 2007 04:55:54 -0500 Original-Received: from ironport2.bredband.com (195.54.101.122) by proxy2.bredband.net (7.3.127) id 47285ABF008BC453 for emacs-devel@gnu.org; Thu, 22 Nov 2007 10:55:51 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoQrAMPgREdT44MDRmdsb2JhbACOOmoBAQE3k3A Original-Received: from ua-83-227-131-3.cust.bredbandsbolaget.se (HELO kurono) ([83.227.131.3]) by ironport2.bredband.com with ESMTP; 22 Nov 2007 10:55:50 +0100 In-Reply-To: <4745446E.6010009@gmx.at> (martin rudalics's message of "Thu\, 22 Nov 2007 09\:57\:18 +0100") User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (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:83851 Archived-At: martin rudalics writes: Would it be possible for emacs to read its files from some kind of archive? That way the issue of different filesystems having substandard support for long filenames wouldnt come up. To elaborate: - some systems work this way so there is precedence(javas jar files for instance) - the el files are already compressed, so also archiving them in a archive blob of some form doesnt seem to be so far away - the archiving system wouldn need to be default, it could be used on old windoze systems and maybe on embedded systems This assumes of course that emacs is built on some other os and the resulting binary delivered to the target system, so maybe the idea falls apart there, I dont know. >>>As I understand it (it's been a fairly long time since I've used the >>>more primitive versions of windows), the "short name" chosen for a long >>>name is explicitly chosen to ensure it doesn't clash with any other >>>short names. E.g., for the file "remember-diary.el", it might choose >>>"rememb~1.el" as a short name. >> >> In theory, yes, but in practice, the algorithm that chooses the short >> 8+3 alias has bugs that could well cause a clash, depending on what >> other files are present in the directory whose names map to the same >> strings after 8+3 truncation, and in what order Windows sees the files >> created. > > FWIW Eli's right: > > (1) If remember.el is created _before_ remember-diary.el, the 8+3 alias > of the former is written to disk as REMEMBER.EL that of the latter as > REMEMB~1.EL (I did use the disk editor to verify that). > > (2) If remember-diary.el is created first, its 8+3 alias is written to > disk as REMEMBER.EL. When I now try to find a file remember.el in the > same directory, Windows finds remember-diary.el instead. When I try to > store a file remember.el in that directory, Windows complains that such > a file already exists. > > In general the problem occurs when the name of the second file I want to > write has eight characters _and_ is a prefix of the name of the first > file. Hence, I get the same bug for remember_diary.el vs remember.el as > well as for rememberdiary.el vs remember.el. > > With other words: When the name of a file A sans extension is a prefix > of the name of a file B sans extension and the length of the name of > file A sans extension equals 8, file A must be created before file B in > order for having both files coexist in the same directory. I didn't > bother to check this rule for filenames containing a tilde. > > My problem with the CVS repository thus could be resolved by renaming > remember.el to something like remember-core.el. -- Joakim Verona