Opened 15 years ago

Closed 13 years ago

#19049 closed defect (wontfix)

port activation fails with "Error: port activate failed: Not a directory"

Reported by: julio.lopez@… Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: base Version: 1.7.0
Keywords: Cc: skymoo (Adam Mercer), mf2k (Frank Schima), raphael@…, francis@…
Port:

Description

The way symbolic links to directories are handled in the registry's file map causes failed installation for various ports. Examples are reported in #16068, #18878, #18380, #16599, #17404 among others.

Besides the failed installation, the registry and the file map are left in an inconsistent state. The packages are said to be installed, however their contents are not added to the file map and not all the files are appropriately installed.

There are workarounds that the port maintainers have put in place for some of the problems. Since this issue is causing bugs in many packages, it'd be desirable if this is handled at the port base level, perhaps in the registry or the file map. Also, it'd be a good idea to include in the documentation a clear explanation and a recommendation for the maintainers about the rule used to handle symbolic links to directories.

The specific problem is that a package A may create a symlink to a directory where some of it's files are installed. When a different package B tries to add a file in a directory where the aforementioned symlink is in the path, then the installation fails with:

DEBUG: Not a directory
    while executing
"filemap set file_map $file $port"
    (procedure "receipt_flat::register_file" line 11)
    invoked from within
"${macports::registry.format}::register_file $file $port"
    (procedure "registry::register_file" line 3)
    invoked from within
"registry::register_file $file $name"
    (procedure "portimage::activate" line 65)
    invoked from within
"portimage::activate $portname [composite_version $portversion [array get variations]] [array get options]"
Error: port activate failed: Not a directory

For example, in the situation reported in #16068, python25 (e.g., @2.5.4_0) creates the following symbolic link:

$ pwd
/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib
$ ls -l
total 8
lrwxr-xr-x  1 root  admin  24 Mar 13 11:41 python2.5 -> /opt/local/lib/python2.5

The py25-pyqt4 port tries to add a file under:

/opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/PyQt4/__init__.py

However, this fails because the link created by python25 is now in the file map and it does not correspond to a directory. The following excerpt from ${prefix}/var/macports/sources/rsync.macports.org/release/base/src/pextlib1.0/filemap.c shows where the test is performed and the taken action.

The Set function (in filemap.c) is in the code path for the following TCL statement:

    filemap set filemapVarName path value
int
Set(SNode** ioRoot, const char* inPath, const char* inValue)
{
	int theResult = 0;

...

		if (theCurrentChar == '/')
		{
			if (theSubnode->fNodeType != kNode)
			{
				theResult = ENOTDIR;
				break;
			}
...

I hope this helps.

Also, it'd be desirable to have command line tools (e.g., portadmin <command>) to test the integrity of the file map and the registry and be able to rebuild or fix an inconsistent file map.

Change History (6)

comment:1 Changed 15 years ago by skymoo (Adam Mercer)

Cc: ram@… added

Cc Me!

comment:2 Changed 15 years ago by mf2k (Frank Schima)

Cc: macsforever2000@… added

Cc Me!

comment:3 Changed 15 years ago by raimue (Rainer Müller)

Milestone: Port BugsMacPorts Future

Thanks for summarizing the issue.

But it would not be correct for port to follow the symlink, so erroring out is all it can do in this situation. The behavior of base is correct.

comment:4 Changed 14 years ago by raphael@…

Cc: raphael@… added

Cc Me!

comment:5 Changed 14 years ago by francis@…

Cc: francis@… added

Cc Me!

comment:6 Changed 13 years ago by jmroot (Joshua Root)

Milestone: MacPorts Future
Resolution: wontfix
Status: newclosed

Closing as per comment:3. The inconsistency issues should be fixed in the sqlite registry at least.

Note: See TracTickets for help on using tickets.