First Last Prev Next    No search results available
Bug 8292 - Photo filename collisions
: Photo filename collisions
Status: RESOLVED DUPLICATE of bug 7758
Product: Images and Camera
Camera
: 5.0/(2.2009.51-1)
: N900 Maemo
: Unspecified normal (vote)
: ---
Assigned To: unassigned
: camera-bugs
:
:
:
:
  Show dependency tree
 
Reported: 2010-01-20 00:04 UTC by bog150
Modified: 2010-01-22 07:58 UTC (History)
3 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)


Note

You need to log in before you can comment on or make changes to this bug.

Description bog150 (reporter) 2010-01-20 00:04:33 UTC 
SOFTWARE VERSION:
(Settings > General > About product)
2.2009.51-1.002
also on 1.2009.44-1 and 1.2009.42-11
EXACT STEPS LEADING TO PROBLEM: 
(Explain in detail what you do (e.g. tap on OK) and what you see (e.g. message
Connection Failed appears))
1. Take several pictures, for example 20100117_001.jpg thru 20100117_004.jpg.
2. Connect the phone via USB as simple mass storage to a Windows PC.
3. Copy those pictures from e:\DCIM (or whatever it's called on your system).
4. Delete those pictures from the phone at e:\DCIM (or whatever...).
5. On the same day, take another picture.
6. It will be called 20100117_004.jpg, colliding with the last picture that was
deleted.

EXPECTED OUTCOME:
Generated picture filenames should never collide.

I appears that you generate picture file names of the form yyyymmdd_sss.jpg,
where yyyymmdd is the date (local time zone) the picture was taken, and sss is
a serail number that resets each day and increments with each new picture.  It
also appears that you remember the name of the last picture taken on a given
day, presumably with the intention to avoid name collisions.  At least I can't
think of any other rationale.

I'd actually prefer that the generated names have a longer serial number sssss
or even ssssss that never resets.  Or perhaps some scheme for allowing me to
specify the format of the filenames you generate.
ACTUAL OUTCOME:
Your picture filename generation mechanism, which appears intended to avoid
collisions, is broken.  Some kind of off-by-one.

REPRODUCIBILITY:
(always, less than 1/10, 5/10, 9/10)
Always.  I only tried fiddling with the pictures via USB from Windows PC, so it
may be that all is groovy if you do the manipluation from the phone, or from
Linux.  All I tried was Windows PC.
EXTRA SOFTWARE INSTALLED:
Lots, but not relevant, I should think.
OTHER COMMENTS:
This shows up because I have some scripts that run on the Windows PC that go
and get the pictures from the phone (or from a camera or...), munge them
appropriately, and send them off to pages on the home website.  The name
collisions mean I have to do extra steps so that a new picture doesn't clobber
an old one.
User-Agent:       Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1;
Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; InfoPath.1; .NET CLR
3.0.4506.2152; .NET CLR 3.5.30729)
Comment 1 Andre Klapper maemo.org 2010-01-20 16:07:14 UTC 
Thanks for reporting this.

> EXACT STEPS LEADING TO PROBLEM: 
> 4. Delete those pictures from the phone at e:\DCIM (or whatever...).
> 5. On the same day, take another picture.
> 6. It will be called 20100117_004.jpg, colliding with the last picture that was
> deleted.

So if I get this right, there is no collision on the N900, but on your Windows
machine if you copy these pictures again?

> ACTUAL OUTCOME:
> Your picture filename generation mechanism, which appears intended to avoid
> collisions, is broken.  Some kind of off-by-one.

What does "off-by-one" exactly mean here?
Comment 2 bog150 (reporter) 2010-01-20 18:03:50 UTC 
> So if I get this right, there is no collision on the N900, but on your Windows
> machine if you copy these pictures again?

You are correct.  The collision is in the names of the photo files, not in any
actual files.  If you take some pictures, then through some means delete them
all, then (on the same day) take another picture, the name of the first picture
in the set taken after deletion collides with the name of the last picture
taken before the deletions.

There is no actual lost data or anything.  It's just the filenames.

I assume the problem is not dependent on the Windows PC aspect of theis, but I
have only tried that path.

> What does "off-by-one" exactly mean here?

It appears to me that some design effort went into preventing photo filename
collisions.  I infer this from the fact that names, after deletions, don't just
start with yyyymmdd_001.jpg, but instead with a name that looks like it is
off-by-one from what would have been correct given my understanding of the
intention.

If you take 3 pictures today
  20100120_001.jpg
  20100120_002.jpg
  20100120_003.jpg
then munge and delete them, then take another, still today, you get
  20100120_003.jpg
As I understand the intent, you should have gotten
  20100120_004.jpg
and the 003 is off-by-one from the 004.

NEWS FLASH

The same problem is present if you don't involve a Windows PC.  I took some
pix, deleted them all with File Manager on the N900, then took another picture,
and the frst one taken after the deletions got the same filename as the last
one taken before the deletions.
Comment 3 Lucas Maneos 2010-01-22 07:58:56 UTC 
This is the same as steps 3..6 in bug 7758.

*** This bug has been marked as a duplicate of bug 7758 ***
First Last Prev Next    No search results available