Re: what happend of the .hidden file in Tiger?
Re: what happend of the .hidden file in Tiger?
- Subject: Re: what happend of the .hidden file in Tiger?
- From: Mason Mark <email@hidden>
- Date: Sun, 28 Aug 2005 14:30:14 +0900
On Aug 28, 2005, at 12:11 PM, Greg wrote:
On Aug 27, 2005, at 8:00 AM, James Bucanek wrote:
Mason Mark wrote on Saturday, August 27, 2005:
On Aug 27, 2005, at 6:16 PM, Finlay Dobbie wrote:
On 27/08/05, James Bucanek <email@hidden> wrote:
This is news to me. I've never had any problem with LS until I ran
your test code. Admittedly, I haven't really tested any of my code
since Tiger, so maybe it's a 10.4 issue. Have you filed a bug
report?
I wouldn't be surprised if the problem was that it's resolving the
symlinks at /tmp, /var, /etc and so on to their corresponding
directories in /private, and then examining the target's HFS
attributes...
The only errors you're getting are because you can't get FSRefs to
/.vol and /dev. If you use URLs rather than FSRefs then LS will
correctly report them as invisible.
Huh, that's an interesting theory! But, not all those files are
symlinks.
By "errors", in this case I meant "Launch Services reporting a
different visibility than what shows up in the Finder", not the
errors getting the FSRef. (Bad choice of words, I suppose.)
Finlay's theory might be right, I don't know. I kept wondering why
Mason's code gave me so many wrong answers that were different
from my own code, which I've been perfectly happy with for some
time. The biggest difference that I could see is that I get my
FSRefs via FSGetCatalogInfoBulk.
So I edited Mason's code snippet and got considerably different
results. What follows is two runs of the code on my PowerBook. The
first uses FSPathMakeRef and the second gets the FSRefs with
FSGetCatalogInfoBulk. In the second run the only anomolies are
mach and mach.sym. Everything else (and I actually tested a number
of other directories) is correct and agrees exactly with what you
see in the Finder. At first blush, it would appear that all of the
differences are, indeed, sym links (which might be resolved by
FSPathMakeRef) or mount points (which FSGetCatalogInfo wouldn't
return in the first place).
So as far as I can tell, LS agrees with the Finder 100% of the
time -- except for mach and mach.sym.
I think the results are in fact 100% correct. The files mach and
mach.sym are visible - and would be seen - were the Finder ever to
show the contents of the "/" directory.
But the Finder never does show the contents of the "/" folder.
Rather it displays a window representing a "toplevel" view of the
entire navigable hierarchy. But note that neither the window's
title nor in its "get info" panel suggest that the contents
displayed are in fact the contents of the "/" directory.
Well, that's not really correct.
You are right that the Finder's top-level virtual "Computer" view
does not display the contents of "/"'. But the Finder does show the
contents of / when you navigate to the root of your boot volume, and
the display of those two files is magically suppressed.
E.g., by default, when you navigate to the root of the disk named
"Macintosh HD".
For the purposes of this discussion you can interchange "/" and "the
root of the boot volume".
--
Mason Mark
Five Speed Software, Inc.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden