It's been suggested that *ix has hardlinks because someone thought up hardlinks before someone thought up symlinks - IOW, there are those who suggest that if people had added symlinks first, no one would've bothered adding hardlinks.

Symlinks are almost always more flexible, and almost always more clear.

The main counterexample seems to be rsync-based backup systems, that will hardlink identical files of a given pathname.  But that seems to be a bit of a mess when it comes time to transfer such a backup from one filesystem to another.

On Tue, Jul 26, 2011 at 3:32 PM, Barry Warsaw <barry@python.org> wrote:
On Jul 27, 2011, at 12:19 AM, Antoine Pitrou wrote:

>Ok, apparently the decision to make hard links for executables dates at
>least back to:

That still doesn't explain *why* hardlinks were originally chosen instead of
symlinks.  In the absence of any other compelling argument against it, I think
they should all consistently be symlinks.  I don't see any Ubuntu or Debian
(where /usr/bin/python3 -> python3.2) bug reports indicating any problems, and
I haven't experienced any issues with it personally.

>changeset:   16221:588691f806f4
>branch:      legacy-trunk
>user:        Neil Schemenauer <nascheme@enme.ucalgary.ca>
>date:        Wed Jan 24 17:11:43 2001 +0000
>files:       Makefile.pre.in
>description:
>Flat makefile based on toplevel Makefile.in and makefiles in build
>subdirectories.  Those other makefiles will go away eventually.
>
>[...]
>
>+# Install the interpreter (by creating a hard link to python$(VERSION))
>+bininstall:    altbininstall
>+       -if test -f $(BINDIR)/$(PYTHON); \
>+       then rm -f $(BINDIR)/$(PYTHON); \
>+       else true; \
>+       fi
>+       (cd $(BINDIR); $(LN) python$(VERSION)$(EXEEXT) python$(EXEEXT))
>+

-Barry

_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/drsalists%40gmail.com