9 Replies Latest reply: May 29, 2012 8:03 AM by Mark Jalbert
Michael Levin Level 2 Level 2 (175 points)

GraphicConverter (an image processing program) is dumping this message onto my console about 2 of my files:

 

bad resource data offset 0 and size -928468624 in file

 

     I routinely check my file system with DiskUtility, Disk Warrior, etc. for any inconsistencies.  I can open the files fine from Finder; what is a "bad resource data offset" and does it mean anything about these files in my file system that I should be concerned about?

  • Mark Jalbert Level 5 Level 5 (4,585 points)

    I think the issue is with the metadata stored in the data fork. If I'm not mistaken GraphicConverter uses Phil Harvey's exiftool (Perl) to operate on the metadata. You might contact the developer.

  • Michael Levin Level 2 Level 2 (175 points)

    do you mean contact the developer of GraphicConverter or Phil Harvey? is there a tool that can check all my files for corrupt metadata in data forks?

  • X423424X Level 6 Level 6 (14,205 points)

    Are you using GraphicConverter 8.0 which was recently released?  I don't see any console messages appearing from it when I launch and quit the app.

  • Mark Jalbert Level 5 Level 5 (4,585 points)

    GraphicConverter. I don't know of a tool that checks for corrupt metadata. There are a number of apps in the App Store that can look at and change metadata, I think that GraphicConverter does. I don't have the application. My guess is "size -928468624 in file" is showing a negative number of bytes in the metadata file size.

  • Michael Levin Level 2 Level 2 (175 points)

    I'm using the latest Beta, and there's a box you can check in the preferences that will make it write debug messages to the console log.

  • Michael Levin Level 2 Level 2 (175 points)

    Ok, but bad resource fork metadata doesn't indicate file system corruption, right? if I can open the file, I can probably ignore this issue, yes?

  • Mark Jalbert Level 5 Level 5 (4,585 points)

    Well, the metadata is not in the resource fork. I think the issue is in the metadata stored in the data fork. It could also be an issue with metadata stored on HFS. Let us see the output from the following command in the Terminal.app. Type the following and the space bar then drag the file on to the Terminal window. The absolute path will appear after the command->

    mdls 
    

    Press the return key.

  • Michael Levin Level 2 Level 2 (175 points)

    Here's what I see when I do mdls on one of those files:

     

    kMDItemContentCreationDate = 2010-08-25 07:10:09 -0400

    kMDItemContentModificationDate = 2010-08-25 07:10:09 -0400

    kMDItemContentType         = "com.adobe.pdf"
    kMDItemContentTypeTree     = (
    "com.adobe.pdf",
    "public.data",
    "public.item",
    "public.composite-content",
    "public.content"

    )

    kMDItemDisplayName         = "pnas00101-0399.pdf"
    kMDItemEncodingApplications= (
    "Apex PDFWriter"

    )

    kMDItemFSContentChangeDate = 2010-08-25 07:10:09 -0400
    kMDItemFSCreationDate      = 2010-08-25 07:10:09 -0400
    kMDItemFSCreatorCode       = ""
    kMDItemFSFinderFlags       = 0
    kMDItemFSHasCustomIcon     = 0
    kMDItemFSInvisible         = 0
    kMDItemFSIsExtensionHidden = 0
    kMDItemFSIsStationery      = 0
    kMDItemFSLabel             = 0
    kMDItemFSName              = "pnas00101-0399.pdf"
    kMDItemFSNodeCount         = 0
    kMDItemFSOwnerGroupID      = 20
    kMDItemFSOwnerUserID       = 501
    kMDItemFSSize              = 1024494
    kMDItemFSTypeCode          = ""
    kMDItemKind                = "Adobe PDF document"
    kMDItemLastUsedDate        = 2012-05-24 07:57:45 -0400
    kMDItemNumberOfPages       = 8
    kMDItemPageHeight          = 747.6
    kMDItemPageWidth           = 493.44
    kMDItemSecurityMethod      = "None"
    kMDItemUsedDates           = (
    "2010-08-25 00:00:00 -0400",
    "2012-05-24 00:00:00 -0400"

    )

    kMDItemVersion             = "1.3"
  • Mark Jalbert Level 5 Level 5 (4,585 points)

    The file is a PDF. I was expecting a JPEG or TIFF file. I think the file is fine. I doubt that the file's resource fork has any data stored. A corrupt file and a corrupt file system are two different things though they can go hand in hand. The journal does a good job keeping files consistent but does not operate on the volume structures in the file system thus a corrupt file system may corrupt files. A corrupt file may be caused by buggy software but the file system stays intact.

    Again, you are using beta software and in debug mode it shows an issue. You should report the issue to the developers of GraphicConverter.