From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Xah Lee Newsgroups: gmane.emacs.help Subject: Re: emacs changed file's own user and file permission Date: Tue, 11 Dec 2007 12:39:37 -0800 (PST) Organization: http://groups.google.com Message-ID: <58019103-c718-4f7a-bbc1-962e7aa1cf9b@i12g2000prf.googlegroups.com> References: <4ad823b9-4941-4883-8771-de43d50913de@e25g2000prg.googlegroups.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1197405662 14169 80.91.229.12 (11 Dec 2007 20:41:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 11 Dec 2007 20:41:02 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Tue Dec 11 21:41:13 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 1J2BuV-0002xR-If for geh-help-gnu-emacs@m.gmane.org; Tue, 11 Dec 2007 21:40:59 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J2BuB-0001Pl-Hv for geh-help-gnu-emacs@m.gmane.org; Tue, 11 Dec 2007 15:40:39 -0500 Original-Path: shelby.stanford.edu!headwall.stanford.edu!newshub.sdsu.edu!border1.nntp.dca.giganews.com!nntp.giganews.com!postnews.google.com!i12g2000prf.googlegroups.com!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 90 Original-NNTP-Posting-Host: 69.236.67.2 Original-X-Trace: posting.google.com 1197405577 2422 127.0.0.1 (11 Dec 2007 20:39:37 GMT) Original-X-Complaints-To: groups-abuse@google.com Original-NNTP-Posting-Date: Tue, 11 Dec 2007 20:39:37 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: i12g2000prf.googlegroups.com; posting-host=69.236.67.2; posting-account=qPxGtQkAAADb6PWdLGiWVucht1ZDR6fn User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/523.12 (KHTML, like Gecko) Version/3.0.4 Safari/523.12, gzip(gfe), gzip(gfe) Original-Xref: shelby.stanford.edu gnu.emacs.help:154590 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:50015 Archived-At: 2007-12-11 Not quite sure what you were saying in your last post. you wrote: "That's on MS-Windows, I presume." Huh? The bang character "!" in the backup file path "!Users!xah!web!emacs!xah_emacs_google_earth.el~" is created by emacs by default. this is stated in the doc for backup-directory-alist Ctrl+h v backup-directory-alist i quote: << Documentation: Alist of filename patterns and backup directory names. Each element looks like (REGEXP . DIRECTORY). Backups of files with names matching REGEXP will be made in DIRECTORY. DIRECTORY may be relative or absolute. If it is absolute, so that all matching files are backed up into the same directory, the file names in this directory will be the full name of the file backed up with all directory separators changed to `!' to prevent clashes. This will not work correctly if your filesystem truncates the resulting name.>> ------------------------ Xah wrote: <> Eli wrote: <> A typical file system usually have limit on the number of chars you can have on a file name. On HFS (used by mac os class) it was 32. HFS+ (OS X) i think its 256. Wikip has more details. Eli wrote: <> Huh?? What do i think is the limit? Are you trying to say, by a rhetorical question, that what i think so is probably not right? If the average file name char length is n, and your file that emacs going to do the backup is in m levels of dir nesting. Then, the backup file char length is n*m+n. m*n+n is a order of magnitude of n. If n is the max length allowed, you can easily see how the emacs scheme easily go beyond it. In real world, probably 99.99% of people will never use more than 10% of the max length in file names, and probably will never have subdirs that are nested more than, say, 10 levels deep. So this means that 99% of those who uses this emacs backup scheme will prob not encounter the problem of it reaching file name legth limit. It will be a problem for sizable number of programers however (maybe hundreds or thousands, worldwide), since there are a software implementations (say, those uses file system as database) easily will make fully use the file name length and dir nesting limit. ... maybe we should do a test to see what happens when emacs reach the file name length limit. Xah xah@xahlee.org $B-t(B http://xahlee.org/ On Dec 10, 8:16 pm, Eli Zaretskii wrote: > > From:XahLee > > Date: Mon, 10 Dec 2007 17:18:46 -0800 (PST) > > > i just tried it and the file is backed up as for example: > > !Users!xah!web!emacs!xah_emacs_google_earth.el~ > > That's on MS-Windows, I presume. > > > i think this is not a robust solution because in principle the file > > name length would quickly reach its limit. > > What limit? What do you think is the limit of a file-name length on > your system? (And what system is that?)