Bug 243718 - Fails to save project configuration
Summary: Fails to save project configuration
Status: RESOLVED WORKSFORME
Alias: None
Product: kdevplatform
Classification: Developer tools
Component: shell (show other bugs)
Version: git master
Platform: Compiled Sources Microsoft Windows
: NOR normal
Target Milestone: 1.0.1
Assignee: kdevelop-bugs-null
URL:
Keywords: triaged
Depends on:
Blocks:
 
Reported: 2010-07-06 06:30 UTC by Konstantin Savenkov
Modified: 2018-10-27 02:12 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 Konstantin Savenkov 2010-07-06 06:30:59 UTC
Version:           SVN (using Devel) 
OS:                MS Windows

When creating a new project, KDevelop creates temporary configuration file for the project. When closing a project, KDevelop tries to copy the temporal project configuration file to the project's directory.

It issues a file copy job, but the jop returns ERR_COULD_NOT_READ error. Indeed, it is not possible to open that temporal file for read.

Either permissions that are used to open the file for copying are wrong or the file is created and opened by KDevelop with too restrictive permissions.

Reproducible: Always

Steps to Reproduce:
Open KDevelop.
Start a new project.
Close the project. 

Actual Results:  
Pop-up saying saveing project config has failed.

Expected Results:  
New file appeared in the project's dir.

I'll try to fix that, but maybe someone with more insight in KDevelop internals will fix that quicker.
Comment 1 Konstantin Savenkov 2010-07-06 07:01:16 UTC
OK, it seems that in the scenario described in my bugreport, the tmp file is only opened at project initialization (project.cpp:312) to get its name, and then immediately closed (project.cpp:314). However, after it is closed, it is still not accessible from Windows. That means it is not *really* closed. Something goes wrong here.
Comment 2 Konstantin Savenkov 2010-07-06 08:40:44 UTC
Exactly. To close KTemporaryFile on OS level, one needs to delete it, not just to call close(). However, in ProjectPrivate class it is not deleted before copying, just closed. Moreover, "KTemporaryFile* tmp" attribute of that class is not deleted anywhere, since the class has no destructor. So we have a memory leak here and locked file, which prevents saving project config under windows.

Probably, KTemporaryFile should be used instantly to get URL of the temp file. Then the file should be accessed as a regular file. What do you think?
Comment 3 Andreas Pakulat 2010-07-06 19:07:54 UTC
Not really a major problem IMHO (except for the still-not-officially-supported windows platform) and there's also no mem-leak as the tmp-file is getting deleted. (see the destructor of Project)
Comment 4 Andreas Pakulat 2010-07-06 19:21:41 UTC
I've just pushed a fix to the 4.0 branch. Unfortunately our keywords seem to be completely broken currently.
Comment 5 Konstantin Savenkov 2010-07-07 05:27:17 UTC
I have debugged this problem a bit deeper.

Windows ProcessMonitor shows, that during initialization of process files, directory /.kdev4 is not found, while statJob->exec() returns no errors (under Windows), so the dir is never created for the new project. Under Linux, statJob->exec() returns a error in that case and the dir is created.

Thus, windows KIO::stat implementation should be fixed.
Comment 6 Andreas Pakulat 2010-07-07 19:51:12 UTC
commit 83417ebd60b86f9f9d06034cd5ac5344f1ba9679
Author: Andreas Pakulat <apaku@gmx.de>
Date:   Tue Jul 6 19:05:57 2010 +0200

    Fix accessing of temp-files for windows.
    
    Keeping the KTempFile around is unecessary and causes problems on
    windows as the underlying file is being kept open.
    
    BUG: 243718

diff --git a/shell/project.cpp b/shell/project.cpp
index 1346740..91b92e3 100644
--- a/shell/project.cpp
+++ b/shell/project.cpp
@@ -142,7 +142,6 @@ public:
     KUrl developerFileUrl;
     QString developerTempFile;
     QString projectTempFile;
-    KTemporaryFile* tmp;
     IPlugin* manager;
     IPlugin* vcsPlugin;
     ProjectFolderItem* topItem;
@@ -308,10 +307,9 @@ public:
         if( !statJob->exec() || !KIO::NetAccess::download( developerFileUrl, developerTempFile,
             Core::self()->uiController()->activeMainWindow() ) )
         {
-            tmp = new KTemporaryFile();
-            tmp->open();
-            developerTempFile = tmp->fileName();
-            tmp->close();
+            KTemporaryFile tmp;
+            tmp.open();
+            developerTempFile = tmp.fileName();
         }
         return true;
     }
@@ -434,7 +432,6 @@ Project::Project( QObject *parent )
     d->project = this;
     d->manager = 0;
     d->topItem = 0;
-    d->tmp = 0;
     d->vcsPlugin = 0;
     d->loading = false;
     d->scheduleReload = false;
@@ -535,11 +532,6 @@ void Project::close()
 {
     Core::self()->projectController()->projectModel()->removeRow( d->topItem->row() );
 
-    if( d->tmp )
-    {
-        d->tmp->close();
-    }
-
     if( !KIO::NetAccess::upload( d->developerTempFile, d->developerFileUrl,
                 Core::self()->uiController()->activeMainWindow() ) )
     {
@@ -548,7 +540,6 @@ void Project::close()
                          "Attention: The project settings you changed will be lost."
                     ) );
     }
-    delete d->tmp;
 }
 
 bool Project::inProject( const KUrl& url ) const
Comment 7 Konstantin Savenkov 2010-07-09 08:45:19 UTC
The bug is still there -- in initProjectFiles, KIO::stat job is used to check whether /.kdev4 exists, and under windows, it returns no errors even if the dir is absent. Therefore, project config dir is never created for a new project.
Comment 8 Kevin Funk 2012-12-22 22:15:49 UTC
Still an issue?
Comment 9 Andrew Crouthamel 2018-09-24 02:00:47 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 10 Andrew Crouthamel 2018-10-27 02:12:18 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!