Bug 120582

Summary: fail to display image with uppercase filename extension
Product: [Fedora] Fedora Reporter: Lewi <ichtus>
Component: gthumbAssignee: Christopher Aillon <caillon>
Status: CLOSED UPSTREAM QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 2CC: wtogami
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-08-30 02:19:59 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Lewi 2004-04-11 11:17:05 UTC
Description of problem:
gthumb in FC2 don't display image with uppercase extension
like .JPG

Version-Release number of selected component (if applicable):


How reproducible:
change a jpg file to test.JPG

Steps to Reproduce:
1.change extension to uppercase
2.launch gthumb
3.fail to display test files
  
Actual results:
image don't show up

Expected results:
show up the files

Additional info:

Comment 1 Andrew Overholt 2004-07-07 03:14:28 UTC
I can get the images to display, but they can't be written (ie.
rotations don't save properly).

Comment 2 Andrew Overholt 2004-07-07 14:52:18 UTC
A more detailed scenario:

1. make test.JPG
2. open gthumb
3. try to rotate the image with the rotate toolbar button -> nothing
4. try to rotate with Image->Transform->Rotate Right
5. move to another image -> prompt for saving the image
6. click 'Save As'
7. keep same filename (with Image Type still at 'Determine by extension')
8. click OK -> prompt for overwriting same file
9. click Yes -> "Image type not supported: application/octet-stream"

If, at step 7, you change 'Image Type' to be JPEG (or whatever type
the image is), you still get the overwriting confirmation, but
afterwards a presented with the save options for that image type.

Comment 3 Christopher Aillon 2004-08-30 02:19:59 UTC
Seems to be fixed in current rawhide, but that's probably because of
some other upstream change.  Marking UPSTREAM since the work here to
fix this had to have been done upstream (it wasn't done here).