Aw: Re: Saving images in a new version
Michael Eschweiler
michael.eschweiler at web.de
Wed Mar 1 20:00:40 GMT 2017
Hi Maik,
>
> This bug is now fixed in digiKam-5.5.0.
>
> https://commits.kde.org/digikam/4fc52d71ac748a864049a1d86e09b2e29f7ca3ad
>
Thanks for the quick answer. Now I hope that the team of opensuse will integrate the new version quickly in the repository...
Michael
>
> On Mittwoch, 1. März 2017 13:59:27 CET Michael Eschweiler wrote:
> > Hi all,
> >
> > I just updated my system from opensuse 13.2 to leap 42.2 with the
> > corresponding update of the bundled digikam (now 5.2.0).
> >
> > Beside the strange behavior related localization - my user has a German
> > localization, but some terms in the menues are in english, others in
> > spanish - there is another _very_ strange behavior:
> > After having finished to work on an imported foto I want to save it in
> > new version, normally in the directory above the directory where the
> > original foto is located. Let's say, the directory structure is the
> > following:
> >
> > -20170228_Alaaf
> >
> > |- raw
> >
> > Now I modified the foto 'test.cr2' from 'raw' and want to store it at
> > '20170228_Alaaf'. Normally the Linux syntaxis allows this by writing to
> > the Store-menue: "../test.jpg". This worked fine until the version which
> > came with opensuse 13.2 (4.6.) but now what digikam does is to save the
> > file at 20170228_Alaaf and at the same time it creates an internal link
> > or something similar simulating a subdirectory named '..'. Afterwards in
> > the album-menu you find this:
> >
> > -20170228_Alaaf
> >
> > |-raw
> > |
> > |-..
> >
> > The newly stored file you will find it in both directories,
> > 20170228_Alaaf and in 20170226_Alaaf/raw/..
> >
> > You can delete, extract or copy the foto from each of both directories but:
> > Now, beware of trying to delete '..' because you'll loose the whole
> > directory '20170228_Alaaf' with all subdirectories.
> >
> > Looking at the Linux system level there is no subdirectory below 'raw'.
> > Therefore I suppose this is an internal problem of digikam. Is there a
> > way to get back to the 'normal' behavior for the storing process.
> >
> > Any help is appreciated!
> >
> > Cheers,
> > Michael
>
>
> --
> Gruß Maik
>
More information about the Digikam-users
mailing list