Opened 14 years ago

Last modified 4 years ago

#28738 new enhancement

Hard links fail with Macports on AFS

Reported by: kev@… Owned by: macports-tickets@…
Priority: Low Milestone:
Component: base Version: 1.9.2
Keywords: Cc:
Port:

Description

Hi, I'm installing Macports over AFS (Apple File System). One thing I've found while installing many of the ports is that hard links don't work on AFS while many ports use them to set locks (libtool), or link the regular executable name (python) to a specific version (python26).

So while I've been installing these I've had to modify the Makefiles by hand, changing all of the ln's to "ln -s" so the port won't fail with an error, or hang while trying to acquire a non-existent lock.

It might be worth detecting AFS in the Port system and then changing all links to symbolic in that case, considering most times there is already an $(LN) variable in the makefile.

Change History (2)

comment:1 Changed 9 years ago by mf2k (Frank Schima)

Component: portsbase
Keywords: afs apple file server links makefile symlinks removed

comment:2 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)

Priority: NormalLow

Apple File System was introduced in macOS High Sierra in 2017. Since this ticket was filed in 2011 you can't have been talking about that. I guess you meant Apple File Service, in other words installing MacPorts to a network volume? I'm not at all surprised that doesn't work so I would suggest not doing that.

It seems pretty infeasible that we would be able to implement the suggestion you proposed, given that there is no standardization among projects regarding how hard links are created, whether an LN variable is used as you claim, nor even whether a project uses Makefiles at all. Some projects build using Xcode or ninja or meson or scons or qmake or who knows what else.

If we do anything about this, I suggest we modify the installer and configure script to detect and prevent installation to a network volume.

Note: See TracTickets for help on using tickets.