Re: emacs changed file's own user and file permission

[Xah Lee]

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:
<<i think this is not a robust solution because in principle the file
name length would quickly reach its limit.>>

Eli wrote:
<<What limit? ...>>

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:
<<What do you think is the limit of a file-name length on your system?>>

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
\xAD\xF4 http://xahlee.org/




On Dec 10, 8:16 pm, Eli Zaretskii <e...@gnu.org> wrote:
> > From:XahLee<x...@xahlee.org>
> > 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?)