Bug 79722

Summary:	AutoProjectPart::slotCompileFile() uses non-robust path test
Product:	[Applications] kdevelop	Reporter:	Craig Scott <craig.scott>
Component:	Build tools: Automake	Assignee:	KDevelop Developers <kdevelop-devel>
Status:	RESOLVED INTENTIONAL
Severity:	normal
Priority:	NOR
Version:	3.0.2
Target Milestone:	---
Platform:	Fedora RPMs
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Craig Scott 2004-04-16 01:57:17 UTC

Version:           3.0.2 (using KDE KDE 3.2.1)
Installed from:    RedHat RPMs

The result returned from projectDirectory() on line 853 of buildtools/autotools/autoprojectpart.cpp may make use of symbolic links. An issue arises in this case when the result for fi.dirPath() on line 847 contains the non-symbolic linked version of the same path. Since slopCompileFile() only tests if the start of the sourceDir string matches the project directory, it believes the paths are different when in fact they are not. As a result, it issues a message box saying "Can only compile files in directories which belong to the project", which is misleading to the user.

A temporary workaround for users is to use an absolute path in the project options for the project directory, although this is problematic if the project needs to be moved around.

Comment 1 Sascha Cunz 2004-04-18 03:04:03 UTC

From what i read in autoprojectpart.cpp, this bug occurs if editorpart's path is not starting with the project path.

Which could be true, if the user really opened a file via a symlinked path that happens to link into the project, too. ( So far my first thought )

OTOH: In chat about this, it came up that in the path names passed to the editor part symlinks are resolved. This'd be another posibility to trigger it.

Both cases should be checked and fixed.

Comment 2 Andreas Pakulat 2008-07-05 21:45:55 UTC

Closing as wontfix as KDevelop3 isn't going to get a fix for this and relevant code doesn't exist in KDevelop4.