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