> On March 27, 2012, 9:56 a.m., Sebastian Kügler wrote: > > Excuse my naivity here, but how does this make sense? If a user asks to > > make certain data private, he expects them to be not available in > > unencrypted fashion anymore. Copying to the encrypted folder doesn't solve > > this, as the file is still available unencrypted, at its previous location. > > > > The user would think his data is protected, while it isn't -> not good. > > > > Or am I missing something here?
In my test I did not ask to make the data private, I just asked to add an app to the homescreen of a private activity. Apps are system resources (owned by root, so it's not user data), there is no sense in making them private or even moving them to the private folder since they will be restored on the next upgrade. Anyway, kamd only tries to move the .desktop, the executable still remains in /usr/bin. I do not know why moving/copying the .desktop is necessary for adding the app to the homescreen. Maybe there is a better solution, that's why I opened this review request instead of commiting the patch. The patch just ry to do not bother the user with an error message that does not make sense to him/her (in despite of the error message the app is added to homescreen). - Lamarque Vieira ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104417/#review11899 ----------------------------------------------------------- On March 26, 2012, 6:04 p.m., Lamarque Vieira Souza wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/104417/ > ----------------------------------------------------------- > > (Updated March 26, 2012, 6:04 p.m.) > > > Review request for KDE Runtime and Plasma. > > > Description > ------- > > When adding an application resource to a private activity kactivitymanager > tries to move the resource's .desktop file to the activity's private folder. > The new .desktop file is created successfully but the source file is not > deleted if the user does not have write permission on the file's directory. > This patch detects such situation and uses copy instead of move to prevent > "permission denied" messages for every resource being added. > > > This addresses bug 296808. > http://bugs.kde.org/show_bug.cgi?id=296808 > > > Diffs > ----- > > service/jobs/nepomuk/Move.h 8a8afd1 > service/jobs/nepomuk/Move.cpp 08a3cc2 > > Diff: http://git.reviewboard.kde.org/r/104417/diff/ > > > Testing > ------- > > Works on Meego devel image. The file is copied and no error message is shown. > > > Thanks, > > Lamarque Vieira Souza > >
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
