FSCatalogInfo randomness

  • Hey everybody,
    I'm using the code below (originally written by Michele Balistreri) to
    determine whether a file is invisible or not (in Tiger). It works very well
    - most of the time. But every once in a while I get really weird results
    where almost all files are flagged as invisible. This happens randomly: the
    exact same code gives different results from time to time. Usually correct,
    sometimes not. Also, I have noticed that one particular file is arbitrarily
    flagged as visible/invisible every time I check it. What's wrong here?

    Thanks.

    - (BOOL) isInvisibleFileAtPath:(NSString *)path

    {

      BOOL isHidden = NO;

      LSItemInfoRecord itemInfo;

      LSCopyItemInfoForURL((CFURLRef)[NSURL URLWithString:path],
    kLSRequestAllFlags, &itemInfo);

      isHidden = (itemInfo.flags & kLSItemInfoIsInvisible);

      FSRef possibleInvisibleFile;

      FSCatalogInfo catalogInfo;

      FSPathMakeRef((unsigned const char *)[path fileSystemRepresentation],
    &possibleInvisibleFile, nil);

      FSGetCatalogInfo(&possibleInvisibleFile, kFSCatInfoFinderInfo,
    &catalogInfo,  nil, nil, nil);

      isHidden |= ((((FileInfo*)catalogInfo.finderInfo)->finderFlags &
    kIsInvisible) ? 1 : 0;

      isHidden |= [path isEqualToString:@"/Network"];

      isHidden |= [path isEqualToString:@"/mach"];

      isHidden |= [path isEqualToString:@"/mach.sym"];

      isHidden |= [path isEqualToString:@"/dev"];

      isHidden |= [path isEqualToString:@"/automount"];

      return isHidden;

    }
  • On 30.10.2007, at 12:38, <slasktrattenator...> wrote:
    > Usually correct,
    > sometimes not. Also, I have noticed that one particular file is
    > arbitrarily
    > flagged as visible/invisible every time I check it. What's wrong here?
    >
    > (...)
    > LSCopyItemInfoForURL((CFURLRef)[NSURL URLWithString:path],
    > kLSRequestAllFlags, &itemInfo);
    >
    > (...)
    > FSPathMakeRef((unsigned const char *)[path
    > fileSystemRepresentation],
    > &possibleInvisibleFile, nil);
    >
    > FSGetCatalogInfo(&possibleInvisibleFile, kFSCatInfoFinderInfo,
    > &catalogInfo,  nil, nil, nil);

      What about checking the return values of these functions? Probably
    one of them is returning some error that you aren't aware of, and
    isHidden is then set based on arbitrary data in an un-initialized
    FSCatalogInfo struct.

      See <http://www.zathras.de/blog-carbon-for-the-cocoa-guy-
    oserror.htm
    > for a description of how to interpret the return values
    from FSGetCatalogInfo, FSPathMakeRef and LSCopyItemInfoForURL.

    Cheers,
    -- M. Uli Kusterer
    http://www.zathras.de
  • On 30 Oct 2007, at 14:27, Uli Kusterer wrote:

    > What about checking the return values of these functions? Probably
    > one of them is returning some error that you aren't aware of, and
    > isHidden is then set based on arbitrary data in an un-initialized
    > FSCatalogInfo struct.
    >
    > See <http://www.zathras.de/blog-carbon-for-the-cocoa-guy-
    > oserror.htm> for a description of how to interpret the return values
    > from FSGetCatalogInfo, FSPathMakeRef and LSCopyItemInfoForURL.

    It isn't strictly speaking a Cocoa question, but---since you bring
    that up---is there a function anywhere that will convert a Carbon
    error number into a meaningful (NS-)string?  Or a database, perhaps,
    of OSStatus return codes?  It'd be really handy to be able to look
    them up quickly without playing the hunting-about-in-the-system-
    headers game.

    Kind regards,

    Alastair.

    --
    http://alastairs-place.net
  • On 30/10/2007, Alastair Houghton <alastair...> wrote:
    > On 30 Oct 2007, at 14:27, Uli Kusterer wrote:
    >
    >> What about checking the return values of these functions? Probably
    >> one of them is returning some error that you aren't aware of, and
    >> isHidden is then set based on arbitrary data in an un-initialized
    >> FSCatalogInfo struct.
    >>
    >> See <http://www.zathras.de/blog-carbon-for-the-cocoa-guy-
    > > oserror.htm> for a description of how to interpret the return values
    >> from FSGetCatalogInfo, FSPathMakeRef and LSCopyItemInfoForURL.
    >
    > It isn't strictly speaking a Cocoa question, but---since you bring
    > that up---is there a function anywhere that will convert a Carbon
    > error number into a meaningful (NS-)string?  Or a database, perhaps,
    > of OSStatus return codes?  It'd be really handy to be able to look
    > them up quickly without playing the hunting-about-in-the-system-
    > headers game.

    In theory, this is what NSError/CFError are for. In practice, there
    isn't really any way of doing it other than grepping the headers at
    the moment. There used to be a little utility on classic for doing it,
    I forget the name.

    -- Finlay
  • On Oct 30, 2007, at 7:36 AM, Alastair Houghton wrote:

    > It isn't strictly speaking a Cocoa question, but---since you bring
    > that up---is there a function anywhere that will convert a Carbon
    > error number into a meaningful (NS-)string?  Or a database, perhaps,
    > of OSStatus return codes?  It'd be really handy to be able to look
    > them up quickly without playing the hunting-about-in-the-system-
    > headers game.

    I use GetMacOSStatusErrorString(), which returns a C string.  Very
    handy for logging.

    --
    adam
  • Thanks all. So far I have not been able to reproduce the problem, but what I
    notice when checking the return status of LSCopyItemInfoForURL is I get
    a paramErr (-50) for *almost* all files and folders in any directory. (The
    other functions return no error). I'm not sure how to interpret that. It's
    obviously not a parameter error since some files return noErr?

    On 10/30/07, Uli Kusterer <witness.of.teachtext...> wrote:
    >
    > On 30.10.2007, at 12:38, <slasktrattenator...> wrote:
    >> Usually correct,
    >> sometimes not. Also, I have noticed that one particular file is
    >> arbitrarily
    >> flagged as visible/invisible every time I check it. What's wrong here?
    >>
    >> (...)
    >> LSCopyItemInfoForURL((CFURLRef)[NSURL URLWithString:path],
    >> kLSRequestAllFlags, &itemInfo);
    >>
    >> (...)
    >> FSPathMakeRef((unsigned const char *)[path
    >> fileSystemRepresentation],
    >> &possibleInvisibleFile, nil);
    >>
    >> FSGetCatalogInfo(&possibleInvisibleFile, kFSCatInfoFinderInfo,
    >> &catalogInfo,  nil, nil, nil);
    >
    > What about checking the return values of these functions? Probably
    > one of them is returning some error that you aren't aware of, and
    > isHidden is then set based on arbitrary data in an un-initialized
    > FSCatalogInfo struct.
    >
    > See <http://www.zathras.de/blog-carbon-for-the-cocoa-guy-
    > oserror.htm> for a description of how to interpret the return values
    > from FSGetCatalogInfo, FSPathMakeRef and LSCopyItemInfoForURL.
    >
    > Cheers,
    > -- M. Uli Kusterer
    > http://www.zathras.de
    >
    >
    >
    >
  • So I just had this problem again. A directory was listed as empty, although
    it isn't. There were no others errors except LSCopyItemInfoForURL
    returned paramErr (-50). But as I said in my previous post, this error is
    returned for almost all files, even when the directory contents is listed
    properly.
    No error. Just arbitrary results. I find this very strange.

    On 10/30/07, <slasktrattenator...> <slasktrattenator...>
    > wrote:
    >
    > Thanks all. So far I have not been able to reproduce the problem, but what
    > I notice when checking the return status of LSCopyItemInfoForURL is I get
    > a paramErr (-50) for *almost* all files and folders in any directory. (The
    > other functions return no error). I'm not sure how to interpret that. It's
    > obviously not a parameter error since some files return noErr?
    >
    > On 10/30/07, Uli Kusterer <witness.of.teachtext...> wrote:
    >>
    >> On 30.10.2007, at 12:38, <slasktrattenator...> wrote:
    >>> Usually correct,
    >>> sometimes not. Also, I have noticed that one particular file is
    >>> arbitrarily
    >>> flagged as visible/invisible every time I check it. What's wrong here?
    >>>
    >>> (...)
    >>> LSCopyItemInfoForURL((CFURLRef)[NSURL URLWithString:path],
    >>> kLSRequestAllFlags, &itemInfo);
    >>>
    >>> (...)
    >>> FSPathMakeRef((unsigned const char *)[path
    >>> fileSystemRepresentation],
    >>> &possibleInvisibleFile, nil);
    >>>
    >>> FSGetCatalogInfo(&possibleInvisibleFile, kFSCatInfoFinderInfo,
    >>> &catalogInfo,  nil, nil, nil);
    >>
    >> What about checking the return values of these functions? Probably
    >> one of them is returning some error that you aren't aware of, and
    >> isHidden is then set based on arbitrary data in an un-initialized
    >> FSCatalogInfo struct.
    >>
    >> See </blog<http://www.zathras.de/blog-carbon-for-the-cocoa-guy-">http://www.zathras.de/blog<http://www.zathras.de/blog-carbon-for-the-coc
    oa-guy-
    >
    >> -carbon-for-the-cocoa-guy-<http://www.zathras.de/blog-carbon-for-the-cocoa-guy->
    >> oserror.htm> for a description of how to interpret the return values
    >> from FSGetCatalogInfo, FSPathMakeRef and LSCopyItemInfoForURL.
    >>
    >> Cheers,
    >> -- M. Uli Kusterer
    >> http://www.zathras.de
    >>
    >>
    >>
    >>
    >
  • On Oct 30, 2007, at 9:14 AM, <slasktrattenator...> wrote:

    > Thanks all. So far I have not been able to reproduce the problem,
    > but what I
    > notice when checking the return status of LSCopyItemInfoForURL is I
    > get
    > a paramErr (-50) for *almost* all files and folders in any
    > directory. (The
    > other functions return no error). I'm not sure how to interpret
    > that. It's
    > obviously not a parameter error since some files return noErr?

    A paramErr (-50) can generally be interpreted as "Bad Input" in which
    case it makes sense that you will sometimes get it, and sometimes not.

    It is possible, even likely, that in this case when it fails you are
    passing nil to LSCopyItemInfoForURL() (because the URLWithString might
    be failing).
    --
    David Duncan
    Apple DTS Quartz and Printing
    <david.duncan...>
  • On Oct 30, 2007, at 17:43 , <slasktrattenator...> wrote:

    > So I just had this problem again. A directory was listed as empty,
    > although
    > it isn't. There were no others errors except LSCopyItemInfoForURL
    > returned paramErr (-50). But as I said in my previous post, this
    > error is
    > returned for almost all files, even when the directory contents is
    > listed
    > properly.
    > No error. Just arbitrary results. I find this very strange.

    [snip]

    >>>> LSCopyItemInfoForURL((CFURLRef)[NSURL URLWithString:path],
    >>>> kLSRequestAllFlags, &itemInfo);

    Perhaps you should try this with [NSURL fileURLWithPath:path] instead
    of +URLWithString:, that could be the reason it thinks you have
    invalid parameters.

    -- Axel
  • I replaced URLWithString with CFURLCreateWithFileSystemPath, which
    eliminated the paramErr. But I don't see why URLWithString would fail? The
    strings are not malformed.

    On 10/30/07, David Duncan <david.duncan...> wrote:
    >
    > On Oct 30, 2007, at 9:14 AM, <slasktrattenator...> wrote:
    >
    >> Thanks all. So far I have not been able to reproduce the problem,
    >> but what I
    >> notice when checking the return status of LSCopyItemInfoForURL is I
    >> get
    >> a paramErr (-50) for *almost* all files and folders in any
    >> directory. (The
    >> other functions return no error). I'm not sure how to interpret
    >> that. It's
    >> obviously not a parameter error since some files return noErr?
    >
    >
    > A paramErr (-50) can generally be interpreted as "Bad Input" in which
    > case it makes sense that you will sometimes get it, and sometimes not.

    It is possible, even likely, that in this case when it fails you are
    > passing nil to LSCopyItemInfoForURL() (because the URLWithString might
    > be failing).
    > --
    > David Duncan
    > Apple DTS Quartz and Printing
    > <david.duncan...>
    >
    >
    >
  • A -50 (paramErr) is also sometimes called "programmers an idiot
    error" as 90% of the time it occurs it is because the developer
    passed the wrong parameters to a function or they didn't error-check
    the results of one function and passed them to another. When dealing
    with files, this can lead to very bad results.

    Always error check in an insanely insane manner when dealing with
    file APIs. Last thing you'd want is a file creation API to work, but
    a permissions setting call to fail.

    Ack, at 10/30/07, <slasktrattenator...> said:

    > So I just had this problem again. A directory was listed as empty, although
    > it isn't. There were no others errors except LSCopyItemInfoForURL
    > returned paramErr (-50). But as I said in my previous post, this error is
    > returned for almost all files, even when the directory contents is listed
    > properly.

    --

    Sincerely,
    Rosyna Keller
    Technical Support/Carbon troll/Always needs a hug

    Unsanity: Unsane Tools for Insanely Great People

    It's either this, or imagining Phil Schiller in a thong.
  • On 30 Oct 2007, at 18:31, <slasktrattenator...> wrote:

    > I replaced URLWithString with CFURLCreateWithFileSystemPath, which
    > eliminated the paramErr. But I don't see why URLWithString would
    > fail? The
    > strings are not malformed.

    Yes they are:

    /Users/You/Somefile is not a valid file URL,

    file:///Users/You/Somefile is.

    See
    http://developer.apple.com/documentation/Cocoa/Reference/Foundation/
    Classes/NSURL_Class/Reference/Reference.html#//apple_ref/occ/clm/
    NSURL/URLWithString:

    Matt
  • On 30.10.2007, at 15:36, Alastair Houghton wrote:
    > It isn't strictly speaking a Cocoa question, but---since you bring
    > that up---is there a function anywhere that will convert a Carbon
    > error number into a meaningful (NS-)string?  Or a database,
    > perhaps, of OSStatus return codes?  It'd be really handy to be able
    > to look them up quickly without playing the hunting-about-in-the-
    > system-headers game.

      There's a couple of applications out there to look them up, but
    AFAIK no API calls (though you could probably check of NSError maybe
    offers a description for an OSStatus, haven't looked into that yet).

      That said, personally I find most errors have such uncommon numbers
    that you can find them easily and quickly by doing a "Find in
    Frameworks" in Xcode.

    Cheers,
    -- M. Uli Kusterer
    http://www.zathras.de
  • On 30.10.2007, at 17:14, <slasktrattenator...> wrote:
    > Thanks all. So far I have not been able to reproduce the problem,
    > but what I notice when checking the return status of
    > LSCopyItemInfoForURL is I get a paramErr (-50) for *almost* all
    > files and folders in any directory. (The other functions return no
    > error). I'm not sure how to interpret that. It's obviously not a
    > parameter error since some files return noErr?

      No, it obviously *is* a param error. What information are you
    requesting? It may be that you're requesting 10 things, and it fails
    doing the 10th one, but the 9 before that were successfully
    retrieved. So, if you're requesting more things than you actually
    use, and that 10th thing is, for example, an attribute that only
    makes sense for files or folders, that could be a reason for it to fail.

      Looking over your code again:

    [NSURL URLWithString:path]

    Shouldn't that be -fileURLWithString:, if your path variable really
    contains a path and not a URL?

    Cheers,
    -- M. Uli Kusterer
    http://www.zathras.de
  • On 10/30/07, Uli Kusterer <witness.of.teachtext...> wrote:

    Shouldn't that be -fileURLWithString:, if your path variable really
    > contains a path and not a URL?

    Yes, that was it (as reported earlier). I thought I was passing in the URL
    string but it was in fact just the path. So I no longer have the paramErr.

    > No, it obviously *is* a param error.

    I find it a little odd, though, that given I was passing in a bad parameter,
    I didn't get a paramErr for ALL files, just most of them...
previous month october 2007 next month
MTWTFSS
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31        
Go to today