[kdepim-runtime/Applications/16.12] resources/shared/singlefileresource: Fix DATA LOSS bug in ical resource which failed to create std.ics if it didn't exist.

[Albert Astals Cid]

El divendres, 30 de desembre de 2016, a les 18:36:51 CET, Ben Cooksley va 
escriure:
> On Thu, Dec 29, 2016 at 12:14 AM, Albert Astals Cid <aacid at kde.org> wrote:
> > El dissabte, 24 de desembre de 2016, a les 15:05:15 CET, Ben Cooksley va
> > 
> > escriure:
> >> On Sat, Dec 24, 2016 at 7:26 AM, Albert Astals Cid <aacid at kde.org> wrote:
> >> > So i guess we're in agreement that we need a new tarball? Or can we
> >> > just
> >> > tell distro packagers to patch it?
> >> > 
> >> > My issue with a new tarball is that i will need to call it 16.12.0.1
> >> > (since i don't want to do 16.12.1 with just kderuntime-changes) and
> >> > then
> >> > distros are going to complain since it has one extra version, and since
> >> > it's not a whole new release we again basically depend on distros
> >> > picking
> >> > up the new tarball.
> >> 
> >> Whichever one works easiest for the packagers I guess.
> >> 
> >> Considering the severity of this issue though (silent data loss) we
> >> should probably make an advisory in about a month's time of which
> >> distributions have failed to patch/upgrade their packages so users are
> >> aware of the risk they are taking.
> > 
> > We only have security advisories AFAIK
> > https://www.kde.org/info/security/
> > 
> > What kind of advisory/way to make the world now were you thinking about?
> 
> A press release of some description would do the job I think.
> I'll admit i'm not sure of the form it should take though.

For now i'll just put it in the KDE Applications 16.12.1 in a relatively 
"prominent" place.

Cheers,
  Albert

> 
> > Cheers,
> > 
> >   Albert
> 
> Cheers,
> Ben
> 
> >> > So may as well just ask them to patch it in?
> >> > 
> >> > Cheers,
> >> > 
> >> >   Albert
> >> 
> >> Cheers,
> >> Ben
> >> 
> >> > El dimarts, 20 de desembre de 2016, a les 21:24:16 CET, David Faure va
> >> > 
> >> > escriure:
> >> >> On mardi 20 décembre 2016 10:29:03 CET Sandro Knauß wrote:
> >> >> > Hey,
> >> >> > 
> >> >> > mmh the description of your problem does not match with the commit
> >> >> > you
> >> >> > have
> >> >> > pushed, or do i miss anything.
> >> >> 
> >> >> The latter, I think ;)
> >> >> 
> >> >> > Your patch is "only doing:
> >> >> > QUrl(mSettings->path()) -> QUrl::fromUserInput(mSettings->path());
> >> >> > right?
> >> >> 
> >> >> Right.
> >> >> 
> >> >> > that means that we still have the problem with schema prefix in the
> >> >> > url?
> >> >> 
> >> >> No, fromUserInput supports both absolute paths and URLs, see API docs.
> >> >> 
> >> >> > And than mCurrentUrl.isLocalFile() is not true and you'll do not
> >> >> > enter
> >> >> > that
> >> >> > codepath?
> >> >> 
> >> >> isLocalFile() will be true for local files and false for remote URLs,
> >> >> I
> >> >> don't see a problem here.
> >> >> 
> >> >> > Just a little bit curious, why this is only a problem for a new
> >> >> > user?
> >> >> 
> >> >> Well, anyone without a ~/.local/share/apps/korganizer/ subdir,
> >> >> which certainly includes new users.
> >> >> 
> >> >> > On the other side I do not understand why the default local is
> >> >> > import
> >> >> > to
> >> >> > trigger this bug.
> >> >> 
> >> >> Parse error at "default local is import". Can you rephrase?
> >> >> 
> >> >> > Btw. if the default location for korganzier has changed, than please
> >> >> > update
> >> >> > the defaultcalendar.desktop path.
> >> >> 
> >> >> And break "Personal Calendar" for all users who copy their home dir
> >> >> (but
> >> >> not their akonadi setup) to another computer? Seems too dangerous to
> >> >> me,
> >> >> for zero gain. The korganizer in the path is historical anyhow,
> >> >> korganizer no longer accesses std.ics directly, ever since akonadi 1
> >> >> came into play.