<folder>_xxx/<subfolder> fails to replicate structure of input tree

Bug #418519 reported by Frank
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Phatch
Fix Released
Critical
Stani

Bug Description

See this thread
http://photobatch.wikidot.com/forum/t-177883/combining-save-and-rename-and-loss-of-exif-tags-during-save

Still unclear why
<folder>_processed/<subfolder> had to create another empty subtree
though.

Source tree was

demo
|-- CementerioRosario.jpg
`-- lev-1
    |-- belongil_beach_HDR.jpg
    `-- lev-2
        `-- Yellowstone1_20040619_bg.jpg

2 directories, 3 files

I told it to process the folder called demo. Expected output was

demo_processed
|-- 2009-8-24-14-19-48.jpg
`-- lev-1
    |-- 2009-8-24-14-19-48.jpg
    `-- lev-2
        `-- 2009-8-24-14-19-48.jpg

And instead I got

demo_processed
|-- lev-1
| `-- lev-2
`-- processed
    |-- 2009-8-24-14-19-48.jpg
    `-- lev-1
        |-- 2009-8-24-14-19-48.jpg
        `-- lev-2
            `-- 2009-8-24-14-19-48.jpg

I can't understand why it created those two empty "lev1/lev2"
directories or why id did an extra "processed" dir inside
"demo_processed".

Revision history for this message
Frank (frank-launchpad-10-fms) wrote :
Revision history for this message
Stani (stani) wrote :

Thanks for reporting this bug.

Just a reminder for myself: check get images in core/api.py

Changed in phatch:
assignee: nobody → stani (stani)
importance: Undecided → Critical
status: New → Confirmed
Revision history for this message
Stani (stani) wrote :

This seems to be fixed in release: phatch_0.2.0.bzr1068

Can you please verify?

Changed in phatch:
status: Confirmed → Fix Committed
Revision history for this message
Frank (frank-launchpad-10-fms) wrote :

No, sorry, this didn't quite work for me yet.

With reference to the same test data and script that I previously supplied:

The input tree is

demo
|-- CementerioRosario.jpg
`-- lev-1
    |-- belongil_beach_HDR.jpg
    `-- lev-2
        `-- Yellowstone1_20040619_bg.jpg

and the sequence of actions is SCALE + SAVE + RENAME.

So I expect to get back that tree untouched, plus a copy of that tree
(demo_processed) with the same structure and pictures in the same
place, except each picture would be scaled and renamed.

What do I get instead? The source tree is emptied of all pictures and
the destination tree now has both the original and the resized
pictures in it:

demo
`-- lev-1
    `-- lev-2
demo_processed
|-- 2009-8-24-14-7-40.jpg
|-- CementerioRosario.jpg
`-- lev-1
    |-- 2009-8-24-14-15-17.jpg
    |-- belongil_beach_HDR.jpg
    `-- lev-2
        |-- 2009-8-24-13-58-10.jpg
        `-- Yellowstone1_20040619_bg.jpg

I would have much preferred for the originals to stay where they were.

Tested on 0.2.0.bzr1138.

Revision history for this message
Stani (stani) wrote :

There is a bug in your action list. The rename and copy action work on the original files. So a rename action will always move the original images. (Normally a rename action is used on its own. Not part of an actionlist unless you want to move the originals.) You need to specify the new filename to the save action and not append an extra rename action.

I've attached a corrected action list. In case that is not what you want, I am misunderstanding you.

Revision history for this message
Frank (frank-launchpad-10-fms) wrote :

Thanks. I cannot see the action list you attached--would you kindly point me at it? In "bug attachments" I can only see my original frank-python.tgz file.

Revision history for this message
Stani (stani) wrote :

Hmm... I probably missed it. The other discussion is best done on the forum we can continue there.

This attachment is a "phatch" ;-)

Revision history for this message
Stani (stani) wrote :
Stani (stani)
Changed in phatch:
milestone: none → 0.2.1
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.