| Summary: | Renaming tool "loose" original filename | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | mnaugendre |
| Component: | AdvancedRename-dialog | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | jonorland, michal, mnaugendre, tschenser |
| Priority: | NOR | ||
| Version: | 1.2.0 | ||
| Target Milestone: | --- | ||
| Platform: | Ubuntu | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | 1.3.0 | |
| Sentry Crash Report: | |||
|
Description
mnaugendre
2010-04-11 10:50:50 UTC
Since the renaming tool itself works fine (in AlbumUI and CameraUI), it is BQM related. The problem also only occurs when using one of the convert tools, so I guess the filename is messed up in these tools. It worked fine in 1.1.0 though. When importing from my camera in PTP mode I can also see this. The [file] option looks like it is returning an empty string. Importing from harddrive or card reader works. It worked in 1.1.0. Rename example: [date:ISO]-[file] Digikam 1.2.0 gives: 2010-04-03T14:11:08-.JPG Digikam 1.1.0 gives: 2010-04-03T14:11:08-IMG_0226.JPG KDE: 4.4.2 Kubuntu 9.10 with Backports PPA In fact the [file] is not empty by itself, but it simply "vanishes" as soon as I add something else on the right, be it some string of my own, a number generated by the batch tool, the camera name, or whatever. (In reply to comment #3) > In fact the [file] is not empty by itself, but it simply "vanishes" as soon as > I add something else on the right, be it some string of my own, a number > generated by the batch tool, the camera name, or whatever. Yes, but still it only happens when you convert the image to some other file format, right? This is the only situation where I can confirm it... 2010/4/18 Andi Clemens <andi.clemens@gmx.net>: > Yes, but still it only happens when you convert the image to some other file > format, right? > This is the only situation where I can confirm it... As I wrote. For me it happens during import from my camera (but only PTP mode not with card reader) and I don't convert to any other format. (In reply to comment #4) > Yes, but still it only happens when you convert the image to some other file > format, right? > This is the only situation where I can confirm it... You're right: I just tested, and if I do only resize+copy, it seems to work OK. SVN commit 1116182 by jmueller: do not update target suffix before advanced renaming take place, because advanced rename check if source path exist (I don't know if this check is needed - Andi?) BUGS: 234022 M +2 -1 NEWS M +6 -4 utilities/queuemanager/queuelist.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1116182 Now modifying the file extension doesn't work anymore... for example:
[date:ISO]_new_####.[ext]{upper}
Andi - you are right - extension substitution must be done before advanced rename take place. But then you got the same error as described in this bug entry. Advanced rename check for file path existance before modifing here: http://lxr.kde.org/source/extragear/graphics/digikam/utilities/advancedrename/parser/options/filepropertiesoption.cpp#73 So you can't change to a new file-extension with advanced rename. From my point of view this check is not necessary and shoul'nt be done inside of advanced rename. But maybe you have any reason to do this here? Regards, Jens SVN commit 1116601 by aclemens: Revert "do not update target suffix before advanced renaming take place...." This reverts commit 65f33ce4ba0d654d358b82b5cfc2e9d126961415. CCBUG:234022 M +0 -10 NEWS M +0 -5 utilities/advancedrename/parser/options/filepropertiesoption.cpp M +4 -6 utilities/queuemanager/queuelist.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1116601 (In reply to comment #9) > From my point of view this check is not necessary and shoul'nt be done inside > of advanced rename. But maybe you have any reason to do this here? > > Regards, Jens I can't remember why I added this... but I guess it is not needed, and since my unit tests still run through ... I removed the file check from the renaming option again ;-) I need to keep the file check though for the directory and metadata option... @Jonas: I guess this should also fix the filename while importing, I haven't checked that yet, because my camera is broken and I need to buy a new one ;-( Andi, If you need a new Nikon device (if i remember your camera that i have tested at previous coding sprint), try D5000. It's excelent. Just tested by a friend... http://www.dpreview.com/reviews/nikond5000/ Gilles Caulier Hi Gilles, yes right... I'm addicted to Nikon (I used to use Canon, but somehow Nikon won my heart now :-)). I will take a look at this cam, too. Thanks for the tip! As this seems to be related to AdvancedRename and not BQM as I initially thought, I'll move the report into the right category... *** Bug 237805 has been marked as a duplicate of this bug. *** |