Saving images in a new version

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Saving images in a new version

Michael Eschweiler-2
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
Reply | Threaded
Open this post in threaded view
|

Re: Saving images in a new version

Maik Qualmann
This bug is now fixed in digiKam-5.5.0.

https://commits.kde.org/digikam/4fc52d71ac748a864049a1d86e09b2e29f7ca3ad

Maik

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
Reply | Threaded
Open this post in threaded view
|

Aw: Re: Saving images in a new version

Michael Eschweiler-2
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
>
Reply | Threaded
Open this post in threaded view
|

Re: Re: Saving images in a new version

Gilles Caulier-4
You can use the 5.5.0 AppImage pre version under OpenSuse :


Gilles Caulier

2017-03-01 21:00 GMT+01:00 Michael Eschweiler <[hidden email]>:
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
>