Prev: Uninstalling Defender
Next: Time Capsule & SuperDuper!
From: Gregory Weston on 5 May 2008 12:34
In article <slrng1ud2b.15qa.g.kreme(a)cerebus.local>,
Lewis <g.kreme(a)gmail.com.dontsendmecopies> wrote:

> In message <uce-D1A7D1.14025630042008(a)newsclstr03.news.prodigy.net>
> Gregory <uce(a)splook.com> wrote:
> > In article
> > <fca95fa1-468e-449c-8b99-fd3acd46ea8c(a)y18g2000pre.googlegroups.com>,
> > "mattdorais(a)gmail.com" <mattdorais(a)gmail.com> wrote:
>
> >> I'm having some major problems with PackageMaker and I have some clues
> >> that might help figure out what's going on. I have an app I created
> >> from an Applescript, I saved it as an application. Using "Get Info" in
> >> Finder tells me that it's 60 KB. Using Terminal "ls -l" tells me that
> >> the exact same app is 13780 bytes large... that's the first strange
> >> part
>
> > ls doesn't show you the size of the resource fork.
>
> Sure it does.

No it doesn't. Not unless told to explicitly (by an inobvious
technique), in which case it won't tell you the size of the data fork.
If you have a file with content in both forks, there is no *single*
invocation of ls that will give you the same number that the Get Info
window will.

--
"Harry?" Ron's voice was a mere whisper. "Do you smell something ... burning?"
- Harry Potter and the Odor of the Phoenix
From: Gregory Weston on 6 May 2008 07:25
In article <slrng1v9gb.15qa.g.kreme(a)cerebus.local>,
Lewis <g.kreme(a)gmail.com.dontsendmecopies> wrote:

> >> > ls doesn't show you the size of the resource fork.
> >>
> >> Sure it does.
>
> > No it doesn't.
>
> Yes it does.
>
> > Not unless told to explicitly
>
> See? You even agree it does.

No, I agree that it *can* if manipulated in a certain way that fewer
people are aware of than you seem to think. It'll tell you the size of
the resource fork by asking it to list the information on a different
file - one that doesn't actually have any logically separate existence,
and the physical existence of which is virtually impossible for a
mainstream user to verify even if they have heard of resource forks and
aren't under the misimpression that they've been excised from OS X.

> > (by an inobvious technique),
>
> Not obvious to you, perhaps. Well documented and well known, however.

Well-known in certain circles. Not obvious and not well-documented. Also
not historically stable and not scaleable. Did you know the OS supports
arbitrary named forks? Do you know how a typical user may find out the
names of the existing forks for any given directory entry?

> > in which case it won't tell you the size of the data fork.
>
> That's incorrect.

For certain definitions of "incorrect" perhaps.

> > If you have a file with content in both forks, there is no *single*
> > invocation of ls that will give you the same number that the Get Info
> > window will.
>
> The same number? That's true, ...


And it's what I said. So happy day.

> $ ls -ls file file.html/rsrc

Oh, excellent. After all this you illustrate the *deprecated* notation.
The supported name has been file.html/..namedfork/rsrc for years. You
want to stand by "well documented and well known" given that you
apparently missed that memo?

--
"Harry?" Ron's voice was a mere whisper. "Do you smell something ... burning?"
- Harry Potter and the Odor of the Phoenix
From: Gregory Weston on 7 May 2008 15:03
In article <slrng23nhl.15qa.g.kreme(a)cerebus.local>,
Lewis <g.kreme(a)gmail.com.dontsendmecopies> wrote:

> In message <uce-A363F6.07254206052008(a)newsclstr03.news.prodigy.net>
> Gregory <uce(a)splook.com> wrote:
> > In article <slrng1v9gb.15qa.g.kreme(a)cerebus.local>,
> > Lewis <g.kreme(a)gmail.com.dontsendmecopies> wrote:
>
> >> >> > ls doesn't show you the size of the resource fork.
> >> >>
> >> >> Sure it does.
> >>
> >> > No it doesn't.
> >>
> >> Yes it does.
> >>
> >> > Not unless told to explicitly
> >>
> >> See? You even agree it does.
>
> > No, I agree that it *can* if manipulated in a certain way
>
> So, ls shows the size of the resource fork if told to show it. That
> fits in with the rest of ls, which, for example, shows the size of the
> data fork *if told to show it*.

ls shows the size of the resource fork associated with a node if and
only if told to show information for a different (synthetic) node that's
not trivially detectable to a typical user. How many other behaviors of
ls are you aware of that are invoked by asking it for information about
a node other than the one in which you're interested?

Go up to a hundred people familiar with Unix-like systems, present them
with the scenario that a file system supports multiple distinct byte
streams for each directory entry but ls by default only shows the
information for the primary stream. Then ask them how they'd expect to
be able to get the information for the additional streams. Most of them
would expect a command-line switch in the vendor's ls implementation.
The rest would expect you're talking about extended attributes and look
for a solution that leverages their prior experiences in that realm. Not
one will start off with: "Well, I'd pretend the file I was interested in
was a directory and blindly type the path of a file with an arbitrarily
chosen name that resides inside that 'directory' hoping that it exists."
It's an idiom that doesn't exist in any other consumer system and is
barely mentioned in any Apple publication, but by your reckoning it's
well-documented and obvious.

> > Well-known in certain circles. Not obvious and not well-documented. Also
> > not historically stable
>
> Oh really? had many crashes of ls with resource forks? really?

I meant stable in the sense of consistent over time. Similar to the way
it's used in the phrase "stable sort." Anyone knowledgeable enough to
take part in this discussion would have recognized that. Be a grown-up,
admit you screwed up and let it go.


> >> > If you have a file with content in both forks, there is no *single*
> >> > invocation of ls that will give you the same number that the Get Info
> >> > window will.
> >>
> >> The same number? That's true, ...
>
> > And it's what I said. So happy day.
>
> No, you said that if it showed the resource fork size it "won't tell you
> the size of the data fork", which statement was, and is, incorrect. The
> only thing ls will not do is combine the size of the two forks into a
> single number.

What I said is *right*up*there*. A dozen lines away. See what it says?
No single invocation that will give you the same number. You haven't
actually demonstrated otherwise; you've just contradicted and provided a
non-general workaround for that reality. Bummer if there's ever a node
with more forks than data and resource, of course.


> >> $ ls -ls file file.html/rsrc
>
> > Oh, excellent. After all this you illustrate the *deprecated* notation.
>
> And Why would I type the extra '..namedfork/' characters if I didn't
> need to?

Because the method you showed is deprecated and if you were actually
trying to be helpful you'd show the *recommended* way rather than the
one that happens to work but might not for much longer and spews
warnings to the system.log every time it's used. I just found it amusing
that right after claiming that it was well documented and implying that
it was obvious you used a technique that isn't officially reliable.
Surely you can see the humor in that.


> let's sum up, shall we:
>
> >> >> > ls doesn't show you the size of the resource fork.
>
> that was wrong

Only if you don't mind having to ask for a different node in the file
system than the one in which you're actually interested. A node the
existence of which can only be posited by an educated guess.

G

--
"Harry?" Ron's voice was a mere whisper. "Do you smell something ... burning?"
- Harry Potter and the Odor of the Phoenix
 | 
Pages: 1
Prev: Uninstalling Defender
Next: Time Capsule & SuperDuper!