Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Remove TYPE codes to avoid possible conflicts Apps
Though old Classic TYPE codes are still useful and used by some applications, when common file extensions are used as well, it can cause problems if they don't match. Some applications seem to prefer file extensions, or examine file contents to make sure of a file's type (i.e. GraphicConverter). Others prefer TYPE codes over file extensions (i.e. Photoshop). So with Photoshop, say, if you have a GIF with the right file extension, but the TYPE code is JPEG, it won't open the file, saying it can't parse the file. If the TYPE is right, but the extension is wrong, it's happy to open it (but you won't be sure what kind of file it is).

So, when a file doesn't open because it's 'damaged' or not the right format or some such problem, the TYPE code could be throwing off the application. Use some file utility (FileShaper, File Buddy, or SetFile if you have the Developer Tools installed) to remove the TYPE code and try file extensions only.

I discovered this little TYPE code problem above in some web graphics I got from a client on a PC CD. A bunch of PNGs. Someone else where I work, with Mac OS 9, copied them to his Mac, and PC Exchange of course gave them all PNGf file TYPEs. But Photoshop 6 wouldn't open them -- "Could not open 'somefile.jpg' because the file-format module cannot parse the file." Turns out they are really JPEGs (thanks GraphicConverter). Photoshop 7 on my OS X Mac gave a more helpful error -- "Could not open 'somefile.jpg' because Brendan's an idiot." The key to getting this odd error message seems to be to use any file that's not a PNG, but that has a PNGf file TYPE; the file extension doesn't matter. I've tried other TYPE mismatches -- GIF, JPEG, TIFF, but they just give the standard parse error.

[robg adds: Photoshop Elements 2.0 gives the standard boring parse error for a mismatched PNGf file TYPE. I had a friend test with Photoshop CS, and my mismatched test file opened perfectly, so apparently they've fixed the issue in the current version of Photoshop. If someone can confirm/deny the humorous message in PS 7, please add a comment. The problem with mis-matched types and extensions is real, at least in PS Elements 2.0 -- if the TYPE is set differently from the file extension, Elements will not be able to open the file.]
    •    
  • Currently 1.20 / 5
  You rated: 1 / 5 (5 votes cast)
 
[14,778 views]  

Remove TYPE codes to avoid possible conflicts | 11 comments | Create New Account
Click here to return to the 'Remove TYPE codes to avoid possible conflicts' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Similar Problem with InDesign
Authored by: Mike Perry on Aug 18, '04 12:18:05PM

This may explain the problem I've been having with InDesign CS thinking TIFF files saved with GraphicConverter are corrupted. All I've had to do to work around it is to load the files into (classic) Photoshop 6.0 and save them as a TIFF. Photoshop must be eliminating some inconsistency introduced by GraphicConverter.

--Mike Perry, Seattle



[ Reply to This | # ]
Similar Problem with InDesign
Authored by: kyngchaos on Aug 18, '04 03:44:42PM

That got me to poking around a bit. This is a bit different. GraphicConverter is writing a valid TIFF file, tho it's a bit odd. A TIFF has a basic header - it identifies it as a TIFF, then says where the metadata starts (and the metadata says where the data starts). Most TIFF writers start the metadata immediately after the header, but GC leaves a few bytes' gap between the header and metadata and specifies so, which is legal.

InDesign is what's broken here - it should follow the offsets to where they lead, but instead (I assume) looks right after the header. I checked and it looks like this happens in ID 2 as well. Photoshop does it right, so it can read it, then writes a TIFF without the gap, which ID likes. Time for a bug report to Adobe.



[ Reply to This | # ]
Script the Finder to empty codes
Authored by: VRic on Aug 18, '04 03:20:58PM
This hint doesn't explain what it is to "remove the type code". To be fair even Apple has had varying positions on the matter. Unless the tools in use offer dedicated presets for this, one needs to know what "empty" type/creator codes really are (NOT empty :-). And once you know this, you don't need dedicated tools any more.

Empty type/creator codes on HFS/HFS+ volumes aren't empty strings: OSType values are tied to the file entry at the filesystem level (not in the resource fork as many believe) and are always exactly 4 bytes, each with a value of 0 for files "without" codes.

The following script for Mac OS X sets the selected files' type & creator codes to 4 null characters as found in "real" un-typed files on HFS/HFS+ volumes (not "????" or 4 spaces, which may still work but I believe aren't sanctioned by Apple any more -- those allowed to specify the existing "unknown" type with characters available on the keyboard, not a default "empty" code that uses null chars).


-- get Finder selection
tell application "Finder"
	set theItems to selection
end tell
if theItems is {} then
	display dialog "Select some files in the Finder to empty their type and creator codes."
end if

-- prepare "empty" OSType value
set nullCh to ASCII character 0
set emptyOSType to nullCh & nullCh & nullCh & nullCh

-- do it
tell application "Finder"
	repeat with thisitem in theItems
		if class of thisitem is document file then
			-- only process documents (not disks, folders, applications, aliases)
			try
				set file type of thisitem to emptyOSType
				set creator type of thisitem to emptyOSType
			on error error_message
				display dialog error_message
			end try
		end if
	end repeat
end tell


[ Reply to This | # ]
Script the Finder to empty codes
Authored by: kyngchaos on Aug 18, '04 04:03:13PM

(I'm a bit flakey when it comes to explaining things ^_^)

With the GUI tools (FileShaper, File Buddy, ...) it's easy - just delete the text from the TYPE text box, and the tool takes care of writing the null characters.

However, I found that with the CLI SetFile (robg added that one to the hint for me), you can't use an empty string, it looks like it really sets it to a zero length string not nulls (at least it caused FileShaper to crash when I tried to check it). So with SetFile you would have to build a null string somehow like with your AppleScript.



[ Reply to This | # ]
Script the Finder to empty codes
Authored by: hypert on Apr 29, '10 11:56:33AM

Thanks - that was a big help to me in clearing some Creator Codes!



[ Reply to This | # ]
Remove TYPE codes to avoid possible conflicts
Authored by: NeutronMonk on Aug 18, '04 03:42:08PM

I tried this with a jpeg set to TYPE PNGf and got the standard parse error with Photoshop 7.0.1 and OSX 10.3.5.



[ Reply to This | # ]
Remove TYPE codes to avoid possible conflicts
Authored by: kyngchaos on Aug 18, '04 03:48:46PM

I think maybe it's not 100% of the time. I had couple times when it didn't happen. I didn't mention it because I thought I had just missed something, and couldn't get it to NOT happen when I tried.



[ Reply to This | # ]
Remove TYPE codes to avoid possible conflicts
Authored by: johnsawyercjs on Aug 19, '04 02:45:46AM

I've heard of this "Could not open 'somefile.jpg' because Brendan's an idiot" message before, so it's not your imagination. I'll assume the person who wrote that error message text into Photoshop was Brendan himself, unless he was blaming someone else for the problem...

I tried it, using Super Get Info to change the Type code on an old 1989 PICT file I've kept around (an old floppy disk startup screen!) to PNGf, but when I tried to open it with Photoshop 7, it didn't give me the error message blaming Brendan--instead, Photoshop displayed "the file-format module cannot parse the file". Then I used Photoshop to create two files, one a PICT and the other a JPEG, and then changed their Type to PNGf and tried to open them, with the same results. I thought of using some utility to search through Photoshop 7 for the reference to Brendan, but then thought better of it since my time was better spent simply believing you're right.



[ Reply to This | # ]
Just out of interest...
Authored by: si08han on Aug 19, '04 03:46:14AM
Here's a link that explains who Brendan is: http://www.computerbits.com/archive/2003/0100/pearce0301.html

[ Reply to This | # ]
Just out of interest...
Authored by: kyngchaos on Aug 19, '04 10:18:01AM

Oooohhhhhhhhh! Duh. I had totally forgotten that I had installed SuperPNG. There it is sitting in my plugins, with Adobe's PNG disabled. I never save directly to PNG any more, I always save for web.

Disabled SuperPNG and enabled Adobe's and it's just the standard parse error now :(



[ Reply to This | # ]
Remove TYPE codes to avoid possible conflicts
Authored by: pjt33 on Aug 25, '04 08:08:38AM

For those not aware of it, /usr/bin/file is useful for determining what file type a file actually is.



[ Reply to This | # ]