Author Topic: Data Loss Bug - Case Sensitive Volume  (Read 360 times)

Offline ybp

  • Newcomer
  • *
  • Posts: 18
    • View Profile
Data Loss Bug - Case Sensitive Volume
« on: June 03, 2019, 06:23:49 PM »
Scenario: case sensitive volume.

This is not rare.

For example, all 32 TB of photos in my area are on case sensitive drives because most web servers are case-sensitive and the photos are ultimately stored on servers using six-eight characters from a 41-character mixed case set of possible characters which has been chosen to eliminate profanity but still basically use most upper and lowercase letters and digits 1-9.

Steps to recreate:

1. Edit a photo like ___1234.JPG with an external tool.

2. Save edited copy of photo in same folder with a name like ____1234_Edit.jpg

3. Add a crop to the photo ____1234_Edit.jpg [from within Photo Mechanic].

4. Then do Command+S to save the crop in the original location as a separate file.

Issue:

Normally the file is saved (and should be) as ____1234_EditA.jpg. However, the original edited photo file is overwritten.

Possible diagnosis:

It seems like a capital extension is used to check for existence since that is the default output preference in PM, but a lowercase extension is used to write the output file since the origin file had a lowercase extension.

I haven't noticed this up until now because all editing tools used capital extensions as did the original files, but a new editing tool has only lowercase and no way to change it.

I realized it was happening and recreated it only after losing about 50 photos edited with this specific tool in the last two days, which were overwritten by crops of them made by Photo Mechanic after doing the editing.

[Changes: added clarification to step three that the crop was added to the edited photo from within photo mechanic, not within the external editing tool that already produced the original edited photo.]

« Last Edit: June 04, 2019, 10:58:16 AM by ybp »

Offline Kirk Baker

  • Senior Software Engineer
  • Camera Bits Staff
  • Superhero Member
  • *****
  • Posts: 20247
    • View Profile
    • Camera Bits, Inc.
Re: Data Loss Bug - Case Sensitive Volume
« Reply #1 on: June 03, 2019, 10:00:51 PM »
Thanks for the info and steps to reproduce.  We'll add your issue to our bug tracking database.

-Kirk

Offline Hayo Baan

  • Uber Member
  • ******
  • Posts: 2428
  • Professional Photographer & Software Developer
    • View Profile
    • Hayo Baan - Photography
Re: Data Loss Bug - Case Sensitive Volume
« Reply #2 on: June 03, 2019, 10:34:19 PM »
Just as a side note: you can have PM prefer the lower case extensions as well. It's what I have had for years on end now (and very much prefer over upper case).
Hayo Baan - Photography
Web: www.hayobaan.nl

Offline dennis

  • President
  • Camera Bits Staff
  • Sr. Member
  • *****
  • Posts: 394
    • View Profile
    • Camera Bits, Inc.
Re: Data Loss Bug - Case Sensitive Volume
« Reply #3 on: June 13, 2019, 02:06:00 PM »
I was unable to recreate this problem on a case-sensitive file system: Mac OS Extended (Case-sensitive, Journaled)

I set my PM Files preferences to use upper case extensions (e.g. ".JPG").

I start with a file "foo.jpg", add a crop, then Save As with no renaming.

This creates a file "foo.JPG" and leaves the original "foo.jpg" untouched.

If I instead set PM Files preferences to use lower case extensions (e.g. ".jpg"), then the Save As produces a file "fooA.jpg" as expected.

So there is no data loss.

Unfortunately, PM's contact sheet is case insensitive and so it will only show one of two files named "foo.jpg" and "foo.JPG" (more than likely the one that occurs first in the directory list).  We will need to update PM to handle case sensitive filenames.

One recommendation is to just stick with lower case filenames.  This works best with other applications like Adobe's.  You can easily rename all your photos to lower case extension in PM. First set Files preference to use lower case extensions, then select your photos and Rename using {filenamebase} variable as the renaming string.

HTH...

--dennis