emacs changed file's own user and file permission

emacs changed file's own user and file permission

[cire]

I am using emacs on windows, have a drive T: mounting a remote host.
while i have edited files, the file permission and owner will be
change, that make the file don't allow user to use. How to fix that
problem? thanks

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

[Eli Zaretskii]

> From: cire <cppiii@gmail.com>
> Date: Sun, 9 Dec 2007 18:11:29 -0800 (PST)
> 
> I am using emacs on windows, have a drive T: mounting a remote host.
> while i have edited files, the file permission and owner will be
> change, that make the file don't allow user to use. How to fix that
> problem? thanks

Try setting backup-by-copying-when-mismatch or backup-by-copying to a
non-nil value.

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

[Xah Lee]

How to stop emacs's backup changing the file's creation date of the
original file?

Put this code in your emacs init file: "(setq backup-by-copying t)"

Explanation: when emacs does a backup, by default it renames the
original file into the backup file name, then create a new file as the
original file. So that, the original file effectively have its
creation date and other meta data completly changed.

Unix-like systems (unixes and linuxes) file systems do not record file
creation date. (this is one of the major fuckup in unixes, and is a
fact few unix people knew, even senior unix sys admins. (I'm not sure
what file system linuxes uses now, but is so up to 2004))

The emacs's default behavior is especially bad for Macs, because once
you edited some file, its file creation timestamp info is effectively
destroyed (and become the time you saved it) This is devastating for
those uninitiated. e.g. you started to use emacs, then after a month
or so, when you one day wanted to know when was a particular file
created, you realized that it's all gone.

(this is one of the major damage unixes has done to the computing
industry)

The reason emacs by default chooses to "rename/mv" instead of the much
sensible copying to create the backup, has 2 major reasons:

(1) Emacs predominantly lives in the unix universe, even though GNU is
anti-unix in principle.

(2) Richard Stallman has a "sharing" mentality. According to the emacs
manual on the backup section, the reason given for default renaming
behavior is because that way people can know who edited the file last.
(i.e. the edited file's owener meta data is the person who last edited
it. It presumes that people work in a shared-code environment)

By far, (1) is the major cause. For (2), we could consider it as a bad
decision (and thus damage to the computing industry) that is
influenced by Richard Stallman's collectivism idealogy.

The issue of (2) is debatable or might even be reasonable given the
time frame emacs is active and influential (roughly 1980s to early
1990s). Because during that time, much computing happens in unixes,
which is a shared system. However, in the current decade, some 99% of
computing machines are used by single-user (i.e. PCs), thus the reason
given in emacs doc for emacs backup's default renaming behavior is
without much pertinence today.

--------
Extra note:

for consideration of modernization of emacs, emacs should have backup
off by default. This is because, when emacs was active and
influencial, the emacs backup is a major convenience. But in the
current decade, there's dizzing array and method of transparent and
automatic backup utilities and or revision control systems. The
emacs's auto-backup (by littering a bunch of ~ files everywhere) is
quaint, and has not been adopted by Windows or Mac (which accounts for
> 99% of computing machines used by people). Litter ~ files today is
more of a distraction than help for vast majority of people today.
-----------

In summary, i hope emacs developers will consider, in order of
importance:

* turn emacs backup off by default.
* set backup-by-copying to non-nil by default.
* Create options so that emacs backup will be all directed into a user
specified directory.

(see http://groups.google.com/group/comp.emacs/msg/4611a42bb3d767b5?dmode=source
for the last item)

  Xah
  xah@xahlee.org
\xAD\xF4 http://xahlee.org/

On Dec 9, 6:11 pm, cire <cpp...@gmail.com> wrote:
> I am using emacs on windows, have a drive T: mounting a remote host.
> while i have edited files, the file permission and owner will be
> change, that make the file don't allow user to use. How to fix that
> problem? thanks

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

[Jason Rumney]

On 10 Dec, 18:42, Xah Lee <x...@xahlee.org> wrote:

> * Create options so that emacs backup will be all directed into a user
> specified directory.

Do you mean backup-directory-alist?

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

[Xah Lee]

On Dec 10, 3:07 pm, Jason Rumney <jasonrum...@gmail.com> wrote:
> On 10 Dec, 18:42,XahLee<x...@xahlee.org> wrote:
>
> > * Create options so that emacs backup will be all directed into a user
> > specified directory.
>
> Do you mean backup-directory-alist?

Thanks. That's very nice, i didn't know about it.

i just tried it and the file is backed up as for example:
!Users!xah!web!emacs!xah_emacs_google_earth.el~

i think this is not a robust solution because in principle the file
name length would quickly reach its limit. Another problem in
principle is that it uses a fixed char, requiring the presumation that
the char does not happen file names. (if the char does happen in file
names, that means the backup files can no longer be simply mapped to
the original names)

----------------------
just to be complete, the code is:
(setq backup-directory-alist '(("" . "/Users/xah/emacs_backup")))

and the alternative solution, which create all the dirs instead of the
“!” and i think should be build in into emacs, is:

; make backup to a designated dir, mirroring the full path
(defun my-backup-file-name (fpath)
  "Return a new file path of a given file path.
If the new path's directories does not exist, create them."
  (let (backup-root bpath)
    (setq backup-root "/Users/xah/emacs_backup")
    (setq bpath (concat backup-root fpath "~"))
    (make-directory (file-name-directory bpath) bpath)
    bpath
  )
)
(setq make-backup-file-name-function 'my-backup-file-name)

(setq backup-by-copying t)

  Xah
  xah@xahlee.org
\xAD\xF4 http://xahlee.org/

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

[Eli Zaretskii]

> From: Xah Lee <xah@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?)

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

[Peter Dyballa]

Am 11.12.2007 um 02:18 schrieb Xah Lee:

> and the alternative solution, which create all the dirs instead of the
> “!” and i think should be build in into emacs, is:

Maybe I make backups for a different purpose than you: I would like  
to be able to restore a changed or deleted file. And even more often  
I want to have pluralism: the choice between a few former versions of  
that file.

Your function does not seem to work in this sense, hiding files in a  
big and vast tree.

--
Greetings

   Pete

One cannot live by television, video games, top ten CDs, and dumb  
movies alone
				– Amiri Baraka, 1999

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?)

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

[Eli Zaretskii]

> From: Xah Lee <xah@xahlee.org>
> Date: Tue, 11 Dec 2007 12:39:37 -0800 (PST)
> 
> 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?

Yes.  Most modern file systems either have no practical limit at all,
or have such a large limit that you will in practice never reach it.

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

[Xah Lee]

Dear Eli Zaretskii moron,

Eli wrote:
《What do you think is the limit of a file-name length on your
system? 》

Xah 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.
 》

Eli replies, the whole of the content in his post:
《Yes.  Most modern file systems either have no practical limit at all,
or have such a large limit that you will in practice never reach it. 》

Note: this post contains unicode chars U+300A and U+300B as quotation
brackets. Google groups may bave botched it.

  Xah
  xah@xahlee.org
\xAD\xF4 http://xahlee.org/

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

[Xah Lee]

Peter Dyballa wrote:

<<Maybe I make backups for a different purpose than you: I would like
to be able to restore a changed or deleted file. And even more often I
want to have pluralism: the choice between a few former versions of
that file.

Your function does not seem to work in this sense, hiding files in a
big and vast tree.
>>

you can easily write a restore-backup function in emacs (possibly
bundled as default) that retores the file from emacs's backup. This
way, the emacs backup system is completely transparent. When a user
needs to retore from backup, she can just Alt-x restore-from-backup.
(either on current buffer or prompt for file name...)

for programers who likes to manually see and get the backup file for
whatever reasons, she can do so easily, since the dir path info is
kept intact.

PS addendum to my previous suggestion about sperater dir for emacs
backup: the default backup dir should be fixed by default such as
".emacs_backup". (as opposed to asking a user to set it.) User can
still change it of course. The thing here is that having a
standardized emacs backup dir location is good.

  Xah
  xah@xahlee.org
\xAD\xF4 http://xahlee.org/

On Dec 11, 1:23 am, Peter Dyballa <Peter_Dyba...@Web.DE> wrote:
> Am 11.12.2007 um 02:18 schriebXahLee:
>
> > and the alternative solution, which create all the dirs instead of the
> > "!" and i think should be build in into emacs, is:
>
> Maybe I make backups for a different purpose than you: I would like
> to be able to restore a changed or deleted file. And even more often
> I want to have pluralism: the choice between a few former versions of
> that file.
>
> Your function does not seem to work in this sense, hiding files in a
> big and vast tree.
>
> --
> Greetings
>
>    Pete
>
> One cannot live by television, video games, top ten CDs, and dumb
> movies alone
>                                 - Amiri Baraka, 1999

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

[Peter Dyballa]

Am 11.12.2007 um 21:49 schrieb Xah Lee:

> PS addendum to my previous suggestion about sperater dir for emacs
> backup: the default backup dir should be fixed by default such as
> ".emacs_backup". (as opposed to asking a user to set it.) User can
> still change it of course. The thing here is that having a
> standardized emacs backup dir location is good.

What about .emacs.d/backups? ~/.emacs.d is quite common, containing  
default.el, auto-save-list or such. It could also  be home for  
session and desktop files, private Elisp ...

BTW, I'd prefer to have the options of "traditional" and unified  
backup. And probably it would be a good idea to have another choice  
between flat and in a tree "unified" backup.


Why is it such a huge problem to make a complete proposal?

--
Greetings

   Pete

The problem with the French is that they don't have a word for «  
entrepreneur ».
				– George W. Bush

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

[Xah Lee]

Peter Dyballa wrote:
「What about .emacs.d/backups? ~/.emacs.d is quite common, containing
default.el, auto-save-list or such. It could also be home for session
and desktop files, private Elisp ...」

Yeah, it's a good suggestion. Thanks.

-------------
I just did a test out of curiosity about what happens when the backup
file name is too long.

Put this is your emacs init file:

(setq backup-directory-alist '(("" . "~/.emacs.d/emacs-backup")))

Then create a file such that its path is very long. Then, emacs's
backup will silently fail (not creating backup at the expected
location). Upon manually switching and reading the “*Messages*”
buffer, i found:
“Cannot write backup file; backing up in /Users/xah/%backup%~”
and indeed the file is backed up there.

The file i tested with is this:

/Users/xah/web/PageTwo_dir/Personal_dir/AliceInWonderland_dir/
123456789 123456789 123456789 123456789 123456789 123456789 123456789
123456789 123456789 123456789/that is one hundred if you dont believe
me you can see it for yourselves and you dummy dont challeng./ano

This is on Mac OS X 10.4.11.

  Xah
  xah@xahlee.org
\xAD\xF4 http://xahlee.org/


On Dec 11, 3:03 pm, Peter Dyballa <Peter_Dyba...@Web.DE> wrote:
> Am 11.12.2007 um 21:49 schriebXahLee:
>
> > PS addendum to my previous suggestion about sperater dir for emacs
> > backup: the default backup dir should be fixed by default such as
> > ".emacs_backup". (as opposed to asking a user to set it.) User can
> > still change it of course. The thing here is that having a
> > standardized emacs backup dir location is good.
>
> What about .emacs.d/backups? ~/.emacs.d is quite common, containing
> default.el, auto-save-list or such. It could also  be home for
> session and desktop files, private Elisp ...
>
> BTW, I'd prefer to have the options of "traditional" and unified
> backup. And probably it would be a good idea to have another choice
> between flat and in a tree "unified" backup.
>
> Why is it such a huge problem to make a complete proposal?

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

[Giorgos Keramidas]

On Mon, 10 Dec 2007 10:42:35 -0800 (PST), Xah Lee <xah@xahlee.org> wrote:
> How to stop emacs's backup changing the file's creation date of the
> original file?
>
> Put this code in your emacs init file: "(setq backup-by-copying t)"

This is sound advice, for the particular question.

> Unix-like systems (unixes and linuxes) file systems do not record file
> creation date. (this is one of the major fuckup in unixes, and is a
> fact few unix people knew, even senior unix sys admins. (I'm not sure
> what file system linuxes uses now, but is so up to 2004))

... but this is wrong.

  $ uname -a
  FreeBSD kobe 8.0-CURRENT FreeBSD 8.0-CURRENT #0: \
  Sun Dec  2 07:32:26 EET 2007     \
  build@kobe:/home/build/obj/home/build/src/sys/KOBE  i386

  $ touch .bashrc

  $ ls -lUT .bashrc
  -rw-------  1 keramida  users  - 4112 Nov 28 22:37:32 2007 .bashrc

  $ ls -lT .bashrc
  -rw-------  1 keramida  users  - 4112 Dec 11 23:25:05 2007 .bashrc

  $

Note the time displayed when the -U option is used.  It's the time my
`.bashrc' file was edited (a few minutes ago), and overwritten by vim.
Had I used Emacs with the `backup-by-copying' option, the time would be
even further back in the past.

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

[Kevin Rodgers]

Xah Lee wrote:
> Unix-like systems (unixes and linuxes) file systems do not record file
> creation date. (this is one of the major fuckup in unixes, and is a
> fact few unix people knew, even senior unix sys admins. (I'm not sure
> what file system linuxes uses now, but is so up to 2004))

Apparently this is a fact that you don't know, either:

http://www.unix.com/showthread.php?p=79750
http://m0j0.wordpress.com/2007/09/17/unix-mtime-vs-ctime/

> The emacs's default behavior is especially bad for Macs, because once
> you edited some file, its file creation timestamp info is effectively
> destroyed (and become the time you saved it) This is devastating for
> those uninitiated. e.g. you started to use emacs, then after a month
> or so, when you one day wanted to know when was a particular file
> created, you realized that it's all gone.

Devastating!

> (this is one of the major damage unixes has done to the computing
> industry)

Uh, ok.  If that's major damage to the computing industry, I'll
take it over the "innovation" of Microsoft -- even Apple had the
good sense to move to Unix.

-- 
Kevin Rodgers
Denver, Colorado, USA

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

[Xah Lee]

In this thread, a moron mentioned how Apple switched to Unix, implying
that unix is good and Apple chose it. I quote: 「... even Apple had the
good sense to move to Unix. 」

i like to briefly address this because it is a ignorance rampant in
the linux/OpenSource type of computing communties.

This kind of statement is kinda after-the-fact ascription.

Apple didn't seek out a unix or unix-like OS when it went looking to
buy a modern OS to replace their out-of-date Mac OS (Classic). Apple,
as a business decision, happened to have bought a OS that happens to
be unix-like. Once Apple got NeXT, it is a inevitability for marketing
to stamp and broadcast how it is Unix based and OpenSource based,
riding the 2 fashions at their height (largely from Linux, Apache,
Perl). Apple computer, thru out its history of innovation and
elegance, wouldn't have touched unix with a 9 meters pole.

Similar after-the-fact ascription happens a lot in unix communities.
For example, there's the "Unix Philosophy", which ascribes a
philosophy of design to the patch-wise hacked-up software that has
little to none design or pre-thought.

Similar is Larry Wall's peddling of his creation the Perl language.
When it opportunistically swelled during the dot com web boom, Larry
wall ascribed his "design" by likening it to natural languages.

Further readings:

* Is Mac OS X Unix?
http://xahlee.org/UnixResource_dir/writ/macosx.html

* The Nature of the "Unix Philosophy"
http://xahlee.org/UnixResource_dir/writ/unix_phil.html

* Perl: Theory vs Practice
http://xahlee.org/UnixResource_dir/writ/theory_practice.html

For a reasonable account of the history of how Apple purchased NeXT
(the basis of Mac OS X), check wikip. You can start search by Apple
History.

  Xah
  xah@xahlee.org
\xAD\xF4 http://xahlee.org/

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

[Joel J. Adamson]

Xah Lee <xah@xahlee.org> writes:

> Apple didn't seek out a unix or unix-like OS when it went looking to
> buy a modern OS to replace their out-of-date Mac OS (Classic). Apple,
> as a business decision, happened to have bought a OS that happens to
> be unix-like. 

Happens to be?  How often do carefully designed things (NEXTSTEP) just
happen to incorporate pieces of other designed things (BSD and Mach)?

[...]

> Apple computer, thru out its history of innovation and elegance,
> wouldn't have touched unix with a 9 meters pole.

Then why did they choose it?

Joel

-- 
Joel J. Adamson
Biostatistician
Pediatric Psychopharmacology Research Unit
Massachusetts General Hospital
Boston, MA  02114
(617) 643-1432
(303) 880-3109

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

[Xah Lee]

The general question here, in our context, that we are debating, in
more specific terms, is this: Is it reasonable, to say that Apple
_choose_ a _unix_ based OS for their next generation of OS today known
as Mac OS X. (by the phrase "choose unix", it is with the implication
that Apple considers unix a good technology in 1996)

If you agree that the above statement is what we are discussing, then
i think you would agree with my answer of no. Otherwise, i can further
expend educational efort if you have worthy questions. But if you do
not agree that the above is what we are debating, then, perhaps you
can put forth the question or paraphrase, then we, or i, may voice our
opinion on what we think.

          *          *          *
Xah wrote:
「Apple didn't seek out a unix or unix-like OS when it went looking to
buy a modern OS to replace their out-of-date Mac OS (Classic). Apple,
as a business decision, happened to have bought a OS that happens to
be unix-like.」

Joe wrote:
「Happens to be?  How often do carefully designed things (NEXTSTEP)
just happen to incorporate pieces of other designed things (BSD and
Mach)?」

You need to understand what is meant by unix. In general, the quality
of understanding and interpretation of phrases is part of knowledge
academically taught in areas of philosophy, literature, social
sciences. So, in general, if you studied a lot philosophy, literature,
or social science subjects, then you are good or better. Otherwise,
you do bad.

To be specific, the term "unix" can be understood or interpreted in
many contexts. Legal, political, social, technical, are the broad
categories. Each aspect of consideration does not garantee us a
unique, unambiguous, definition of what is meant by "unix".

          *          *          *

Now, suppose, Microsoft went bankrupt tomorrow and the court orders
that MS Windows and all MS software products are now public domain.
Now, to the Opensource and unix morons, there is a big question
whether we should use it.
On one hand, it's a god-sent JOY. On the other, the tale-telling
overnight obsolescence of unixes might reveal what a hypocrite the
unixers've been in the past decades.

What can we do??????

Don't worry. MS Windows, is unix too. (you the reader, do the home
work and supply the reasons here)

Further readings:

* The Unix Pestilence
http://xahlee.org/UnixResource_dir/freebooks.html

  Xah
  xah@xahlee.org
\xAD\xF4 http://xahlee.org/

On Dec 12, 8:59 am, jadam...@partners.org (Joel J. Adamson) wrote:
> XahLee<x...@xahlee.org> writes:
> > Apple didn't seek out a unix or unix-like OS when it went looking to
> > buy a modern OS to replace their out-of-date Mac OS (Classic). Apple,
> > as a business decision, happened to have bought a OS that happens to
> > be unix-like.
>
> Happens to be?  How often do carefully designed things (NEXTSTEP) just
> happen to incorporate pieces of other designed things (BSD and Mach)?
>
> [...]
>
> > Apple computer, thru out its history of innovation and elegance,
> > wouldn't have touched unix with a 9 meters pole.
>
> Then why did they choose it?
>
> Joel
>
> --
> Joel J. Adamson
> Biostatistician
> Pediatric Psychopharmacology Research Unit
> Massachusetts General Hospital
> Boston, MA  02114
> (617) 643-1432
> (303) 880-3109

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

[Joel J. Adamson]

Xah Lee <xah@xahlee.org> writes:

> Joe wrote:
> 「Happens to be?  How often do carefully designed things (NEXTSTEP)
> just happen to incorporate pieces of other designed things (BSD and
> Mach)?」

No, he didn't.

> You need to understand what is meant by unix. 

I think I understand it pretty well.

> Now, to the Opensource and unix morons, there is a big question
> whether we should use [Windows]

No question in my mind.  

> What can we do??????
>
> Don't worry. MS Windows, is unix too. (you the reader, do the home
> work and supply the reasons here)

Dude, you're mental.  I'm not going to dignify your perseverations with
an intellectual response.  I should have just left your postings marked
as read like I usually do.

joeL
-- 
Joel J. Adamson
Biostatistician
Pediatric Psychopharmacology Research Unit
Massachusetts General Hospital
Boston, MA  02114
(617) 643-1432
(303) 880-3109

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

[Sean Sieger]

   Dude, you're mental.  I'm not going to dignify your perseverations with
   an intellectual response.  I should have just left your postings marked
   as read like I usually do.

I have never understood why anyone has ever responded to Troll Guy.

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

[Barry Margolin]

In article <mailman.4908.1197434250.18990.help-gnu-emacs@gnu.org>,
 Kevin Rodgers <kevin.d.rodgers@gmail.com> wrote:

> Xah Lee wrote:
> > Unix-like systems (unixes and linuxes) file systems do not record file
> > creation date. (this is one of the major fuckup in unixes, and is a
> > fact few unix people knew, even senior unix sys admins. (I'm not sure
> > what file system linuxes uses now, but is so up to 2004))
> 
> Apparently this is a fact that you don't know, either:
> 
> http://www.unix.com/showthread.php?p=79750
> http://m0j0.wordpress.com/2007/09/17/unix-mtime-vs-ctime/

What point are you trying to make with these references?  They both 
describe ctime, which is NOT the file creation date.  They agree with 
Xah's statement of fact, although they don't state an opinion about the 
design decision like he does.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***