emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Avoid duplicate emacs.exe / emacs-$version.exe


From: Eli Zaretskii
Subject: Re: Avoid duplicate emacs.exe / emacs-$version.exe
Date: Sun, 29 Mar 2020 05:31:32 +0300

> From: Juan José García-Ripoll
>  <address@hidden>
> Date: Sat, 28 Mar 2020 21:41:51 +0100
> 
> > No, they don't waste space, at least not by default.  When you install
> > Emacs, the installation procedure produces a hard link with another
> > name to the same file data.  These two names are just 2 different
> > names that refer to the same disk space. [...]
> > This means your installation procedure is modified, or maybe you
> > installed a binary someone else produced, in which case the archive
> > used to package the binaries didn't support hard links.  You can
> > restore the hard link by removing onhe of the copies and making a hard
> > link to the remaining copy under the other name.
> 
> I am reporting figures that come from either (a) the official release
> from ftp.gnu.org, (b) the prerelease *.zip files from alpha.gnu.org and
> (c) the official build process as reported in emacs-27/nt.

AFAIK, the ZIP archive indeed doesn't support hard links, at least not
on MS-Windows.  But you can recreate the hard link locally, if you
want, after unzipping the archive.

> - Building from emacs-27 branch (Savannah's git), following the
>   instructions from nt/ (i.e. configure + make install), creates two
>   identical files, emacs.exe and emacs-27.0.90.exe. Space usage is as in
>   26.3, about 123Mb per executable.

They aren't 2 files, they are 2 _names_.  Look at the link count of
each file, and you will see 2, not 1.

> So I am using stock files, never my own copies. I am using also standard
> procedures. I do not understand why the executable sizes differ so much
> between release, prerelease and built from sources. However, there are
> no symbolic links happening at all. Indeed, MSYS's "ln" as used in the
> autoconf build process does not seem to work: it just copies the file.

I didn't say symbolic links, I said hard links.

> $ ln -sf foo faa

Not "ln -s", just "ln".

> So maybe you are discussing what happens in Linux or Mac systems?

It happens on all supported systems.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]