distutils should not assume that hardlinks will work

[samtygier]

BPO	8876
Nosy	@malemburg, @birkenfeld, @pitrou, @larryhastings, @benjaminp, @tarekziade, @merwok, @ssbarnea
Files	hardlink-traceback.txt distutil-hardlink-trunk.diff copy_file_link_fail.patch

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2014-10-30.18:54:39.408>
created_at = <Date 2010-06-02.13:38:35.110>
labels = ['type-bug', 'library']
title = 'distutils should not assume that hardlinks will work'
updated_at = <Date 2014-10-30.19:14:46.538>
user = 'https://bugs.python.org/samtygier'

bugs.python.org fields:

activity = <Date 2014-10-30.19:14:46.538>
actor = 'eric.araujo'
assignee = 'none'
closed = True
closed_date = <Date 2014-10-30.18:54:39.408>
closer = 'pitrou'
components = ['Distutils']
creation = <Date 2010-06-02.13:38:35.110>
creator = 'samtygier'
dependencies = []
files = ['17521', '17522', '37069']
hgrepos = []
issue_num = 8876
keywords = ['patch']
message_count = 24.0
messages = ['106881', '106885', '106886', '164543', '164545', '164546', '164554', '186994', '186996', '188970', '208191', '208776', '208792', '211180', '229298', '230211', '230213', '230215', '230242', '230250', '230283', '230285', '230286', '230290']
nosy_count = 14.0
nosy_names = ['lemburg', 'georg.brandl', 'pitrou', 'larry', 'benjamin.peterson', 'tarek', 'eric.araujo', 'ssbarnea', 'samtygier', 'python-dev', 'olliewalsh', 'fkochem', 'dfarrell07', 'Matt.Wright']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue8876'
versions = ['Python 2.7', 'Python 3.4', 'Python 3.5']

[samtygier]

distutils will currently try to use hardlinks if os has a 'link' attribute, however sometimes os.link() will fail, for example the filesystem may not support it (see attached traceback).

in commands/sdist.py in make_release_tree() there is the test:
if hasattr(os, 'link'): # can make hard links on this system
link = 'hard'
msg = "making hard links in %s..." % base_dir

'link' is then passed to copy_file() in file_util.py, which trusts that if link == 'hard', then hardlinking will work.

there has been discussion in the past, but i dont think it has been fixed
http://thread.gmane.org/gmane.comp.python.distutils.devel/2076

[samtygier]

here is a patch against http://svn.python.org/projects/python/trunk

it moves the return statements into the individual file copying sections, and takes the final call to _copy_file_contents() out of the else. this allows an error in hardlinking to fall through by passing the exception.

i have only tested on Linux.

when running it still prints out
"hard linking CHANGES -> pyzgoubi-0.4dev"
because of how the message is generated in line 130. do you think this needs to be changed. do we need a
"hardlinking failed, falling back to copy"
message? it might cause unnecessary worry (distutils already suppresses tracebacks to avoid scaring non-python-programmers).

i have a patch that applies to 2.6 as well, is there much chance of that being accepted?

[merwok]

Distutils is a special case: Many third-party code relies on its undocumented quirks and bugs, so it’s basically frozen. Some non-disruptive bugfixes are accepted, in which case the normal Python rules apply (e.g., no new features in 2.7 which is in beta). Work has been moved to Distutils2, which breaks compatibility in order to fix things and add needed features.

If Tarek (maintainer of both packages) agrees this can go into Distutils, Benjamin Peterson (release manager) will say whether he agrees or not. Patient a while for Tarek to see this bug report, and thanks for your work :)

[merwok]

AFAICT using hard links only serves to save up a little time and disk space; it seems to me that always copying would solve one or two bugs at a small cost (not so small for large projects, I don’t know). Could this impact setup scripts? Maybe if os.link were monkey-patched and expected to be called. I could ask on distutils-sig.

In bpo-15205 Ollie noted this: “distutils2 appears to always copy instead of hardlinking resolving all of these issues”. That would be because d2 uses shutil.copytree and distutils.util.copy_file (yes, a function from distutils1 because of some Windows issue :().

[merwok]

Of course the conservative fix would be to try linking as of now and do a copy when an exception is caught, as was proposed.

FTR python.org link to the thread mentioned: http://mail.python.org/pipermail/distutils-sig/2005-August/004954.html

[merwok]

samtygier’s patch to implement the fallback-to-copy idea looks good. Not sure if an automated test would be written, but samtygier says it was manually tested.

[pitrou]

AFAICT using hard links only serves to save up a little time and disk
space; it seems to me that always copying would solve one or two bugs
at a small cost

I agree with this.

[ssbarnea]

Can we have this merged, it prevents us form using distutil, especially in a continuous integration environment where you do not have control over the build server.

See: https://drone.io/github.com/pycontribs/tendo/1

[merwok]

I’ll get this in the next bugfix releases.