Bug 79722 - AutoProjectPart::slotCompileFile() uses non-robust path test
Summary: AutoProjectPart::slotCompileFile() uses non-robust path test
Status: RESOLVED INTENTIONAL
Alias: None
Product: kdevelop
Classification: Applications
Component: Build tools: Automake (show other bugs)
Version: 3.0.2
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: KDevelop Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-04-16 01:57 UTC by Craig Scott
Modified: 2008-07-05 21:45 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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.