[9fans] [Fwd: road sign]

[9fans] [Fwd: road sign]

[Ronald G Minnich]

[-- Attachment #1: Type: text/plain, Size: 84 bytes --]

I apologize in advance for the size of this but ... what a great road sign!

ron

[-- Attachment #2: road sign --]
[-- Type: message/rfc822, Size: 157337 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 126 bytes --]

Here's a road sign I saw up in Saratoga Springs this last week.  I  
figured you'd appreciate the name of the road.

-m


[-- Attachment #2.1.2.1.1: Type: text/plain, Size: 350 bytes --]

from postmaster@ethel:
The following attachment had content that we can't
prove to be harmless.  To avoid possible automatic
execution, we changed the content headers.
The original header was:

	Content-Transfer-Encoding: base64
	Content-Type: application/applefile;
	name="IMG_3043.JPG"
	Content-Disposition: inline;
	filename=IMG_3043.JPG

[-- Attachment #2.1.2.1.2: IMG_3043.JPG.suspect --]
[-- Type: application/octet-stream, Size: 58123 bytes --]

Re: [9fans] [Fwd: road sign]

[Russ Cox]

http://swtch.com/9p.jpg
(for those who can't read whatever format the attachment was.)

russ

Re: [9fans] [Fwd: road sign]

[erik quanstrom]

apple's mail program has sent some goofy mime headers. Note the
"multipart/appledouble". this definately isn't part of the rfcs.

(the output included here is a little strange because it's the mimetypes /after/ charset
conversion and de-transfer-encoding. output from a program that only i suffer from.
subparts of "multipart/appledouble" don't appear because it's not recognized.)

; ./mimedesc $m/1128992546.9661*
Content-Type: multipart/mixed;
	boundary=------------000409010601080409080502
.00Content-Type: text/plain; charset=utf-8
.01Content-Type: message/rfc822;
	name="road sign"
.01.00Content-Type: multipart/mixed;
	boundary=Apple-Mail-3-273748659
.01.00.00Content-Type: text/plain; charset=utf-8
.01.00.01Content-Type: multipart/appledouble;
	boundary=Apple-Mail-4-273748660

Russ Cox <rsc@swtch.com> writes

| 
| http://swtch.com/9p.jpg
| (for those who can't read whatever format the attachment was.)
| 
| russ

Re: [9fans] [Fwd: road sign]

[erik quanstrom]

i'm not sure if this is quite right (does apple publish specs on this junk?),
but treating "multipart/appledouble" as "multipart/alt" and picking the
first sub document that is not of type "application/applefile" seems to
do the right thing. this Content-Type tree now:

Content-Type: multipart/mixed;
	boundary=------------000409010601080409080502
.00Content-Type: text/plain; charset=utf-8
.01Content-Type: message/rfc822;
	name="road sign"
.01.00Content-Type: multipart/mixed;
	boundary=Apple-Mail-3-273748659
.01.00.00Content-Type: text/plain; charset=utf-8
.01.00.01Content-Type: image/jpeg;
	name="IMG_3043.JPG"

"erik quanstrom" <quanstro@quanstro.net> writes

| 
| apple's mail program has sent some goofy mime headers. Note the
| "multipart/appledouble". this definately isn't part of the rfcs.
| 
| (the output included here is a little strange because it's the mimetypes /after/ charset
| conversion and de-transfer-encoding. output from a program that only i suffer from.
| subparts of "multipart/appledouble" don't appear because it's not recognized.)
| 
| ; ./mimedesc $m/1128992546.9661*
| Content-Type: multipart/mixed;
| 	boundary=------------000409010601080409080502
| .00Content-Type: text/plain; charset=utf-8
| .01Content-Type: message/rfc822;
| 	name="road sign"
| .01.00Content-Type: multipart/mixed;
| 	boundary=Apple-Mail-3-273748659
| .01.00.00Content-Type: text/plain; charset=utf-8
| .01.00.01Content-Type: multipart/appledouble;
| 	boundary=Apple-Mail-4-273748660
| 

Re: [9fans] [Fwd: road sign]

[Chris Collins]

erik quanstrom was once rumoured to have said:
> apple's mail program has sent some goofy mime headers. Note the
> "multipart/appledouble". this definately isn't part of the rfcs.

No, but the RFCs never really covered correct handling of 'forked'
binary files (such as those found on Macs).

appledouble encoding at least gives everybody else a hope of
compatability by dividing the data and resource forks into seperately
encoded streams, whilst still letting another mac reconstruct the
stream correctly at the other end.

C.

Re: [9fans] [Fwd: road sign]

[Jeff Sickel]

On Oct 10, 2005, at 9:49 PM, Chris Collins wrote:

> erik quanstrom was once rumoured to have said:
>
>> apple's mail program has sent some goofy mime headers. Note the
>> "multipart/appledouble". this definately isn't part of the rfcs.
>>
>
> No, but the RFCs never really covered correct handling of 'forked'
> binary files (such as those found on Macs).

Thankfully, even Apple on OS X has slowly gone away from the blasted  
Resource Forks.  Sure, you can still use them (if you're Adobe), but  
none of the Cocoa or CoreFoundation APIs go out and encourage to  
resource forks any more.

That said, Mail.app does show it's NeXTMail heritage and do some  
things that make other people and mail transports a little mad.  But,  
at least it doesn't force in line breaks like the other evil empire's  
mail program.  I've spent too much time having to talk people through  
a URL that gets broken w/ a LF/CR breaking it in two.

jas

Re: [9fans] [Fwd: road sign]

[David Leimbach]

> >
> > No, but the RFCs never really covered correct handling of 'forked'
> > binary files (such as those found on Macs).
>
> Thankfully, even Apple on OS X has slowly gone away from the blasted
> Resource Forks.  Sure, you can still use them (if you're Adobe), but
> none of the Cocoa or CoreFoundation APIs go out and encourage to
> resource forks any more.

No but the whole OS pretty much relies on storing things in extended
attributes now.  Even the resource forks can be found there now.  [I
believe this is also where ACLs are stored but don't quote me on this]

Why does a file need to be like a directory?  Isn't that what
directories are for? :)

Dave

Re: [9fans] [Fwd: road sign]

[Chris Collins]

David Leimbach was once rumoured to have said:
> Why does a file need to be like a directory?  Isn't that what
> directories are for? :)

Funnily enough, if you're following the new Mac Order on OSX, thats
exactly what you do use -- bundles are directories :)

C.

Re: [9fans] [Fwd: road sign]

[Uriel]

when I hear about resource forks or extended attributes I reach for my
MP5.

apple latest "innovation" is to fuck up tar, zip, and I think even cp
and mv to pass around their wonderful crap.

a file I got from a graphic design company we work with:

; ls
Linsbilder_JPG.zip
; file Linsbilder_JPG.zip
Linsbilder JPG.zip: Zip archive data, at least v2.0 to extract
; unzip Linsbilder_JPG.zip >/dev/null
$ ls -l
drwxr-xr-x  2 uriel uriel    4096 2005-10-04 10:15 Linsbilder JPG
-rw-r--r--  1 uriel uriel 5801742 2005-10-11 08:56 Linsbilder_JPG.zip
drwxr-xr-x  3 uriel uriel    4096 2005-10-11 09:01 __MACOSX
; ls -l __MACOSX
total 4
drwxr-xr-x  2 uriel uriel 4096 2005-10-11 09:01 Linsbilder JPG
; ls -l '__MACOSX/Linsbilder JPG/'
[nothing!]
; ls -la '__MACOSX/Linsbilder JPG/'
total 1156
drwxr-xr-x  2 uriel uriel  4096 2005-10-11 09:01 .
drwxr-xr-x  3 uriel uriel  4096 2005-10-11 09:01 ..
-rw-r--r--  1 uriel uriel 37848 2005-10-04 10:15 ._01.jpg
-rw-r--r--  1 uriel uriel 37929 2005-10-04 10:14 ._02.jpg
-rw-r--r--  1 uriel uriel 37837 2005-10-04 10:15 ._03.jpg
[...]
-rw-r--r--  1 uriel uriel    70 2005-10-04 10:07 ._.DS_Store
; file '__MACOSX/Linsbilder JPG/._01.jpg'
__MACOSX/Linsbilder JPG/._01.jpg: AppleDouble encoded Macintosh file

20h, get those physics packages ready, we have some fireworks to make
around Cupertino.

unix has become so disgusting that people covers it's crap with a tick
layer of sparkling sugar, but in the end maybe it will be the sugar that
kills you.

the new holy trinity: MacOS X, Google, and Firefox.

doing a boyd maybe, but someone had to do it.

uriel

P.S.: Oh, and don't you love their new XML based init system[0]?! "The unix
of the 21th century" indeed.

[0] http://developer.apple.com/macosx/launchd.html

On Mon, Oct 10, 2005 at 10:52:56PM -0700, David Leimbach wrote:
> > >
> > > No, but the RFCs never really covered correct handling of 'forked'
> > > binary files (such as those found on Macs).
> >
> > Thankfully, even Apple on OS X has slowly gone away from the blasted
> > Resource Forks.  Sure, you can still use them (if you're Adobe), but
> > none of the Cocoa or CoreFoundation APIs go out and encourage to
> > resource forks any more.
> 
> No but the whole OS pretty much relies on storing things in extended
> attributes now.  Even the resource forks can be found there now.  [I
> believe this is also where ACLs are stored but don't quote me on this]
> 
> Why does a file need to be like a directory?  Isn't that what
> directories are for? :)
> 
> Dave

Re: [9fans] [Fwd: road sign]

[leimy2k]

> David Leimbach was once rumoured to have said:
>> Why does a file need to be like a directory?  Isn't that what
>> directories are for? :)
> 
> Funnily enough, if you're following the new Mac Order on OSX, thats
> exactly what you do use -- bundles are directories :)

That's the "directory treated as a file".  That makes more sens

All this named attributes on files crap just bugs me.  Makes life harder to deal with not easier.  Good luck copying files from one system to the next in a lossless way.


Dave

Re: [9fans] [Fwd: road sign]

[erik quanstrom]

two points.

1. osx != unix

2. you're complaining about apple applications; not the operating system.
unless i'm missing something

- erik

Uriel <uriell@binarydream.org> writes

| unix has become so disgusting that people covers it's crap with a tick
| layer of sparkling sugar, but in the end maybe it will be the sugar that
| kills you.
| 
| the new holy trinity: MacOS X, Google, and Firefox.
| 
| doing a boyd maybe, but someone had to do it.
| 
| uriel

Re: [9fans] [Fwd: road sign]

[Jeff Sickel]

On Oct 11, 2005, at 2:25 AM, Uriel wrote:

> when I hear about resource forks or extended attributes I reach for my
> MP5.
>
> apple latest "innovation" is to fuck up tar, zip, and I think even cp
> and mv to pass around their wonderful crap.

You missed my comment "read Adobe".

> a file I got from a graphic design company we work with:

And because of that ... I'd wager you got a jpg from a graphic design  
company that was using Photoshop or Quark, which still embed resource  
forks into all the files they save so they can get nice little  
"thumbnails" to show up in the worst piece of software Apple has on  
the market: the Finder.  None of the Cocoa API applications use  
resource forks by default anymore, only the applications written by  
old Mac-heads tend to do that.

So, besides the ACLs and other cruft that 10.4 produced to get 64bit  
file systems supported, the 'new' BSD based versions of cp/mv/tar/zip  
do proper checking in case a resource fork just happens to be there  
(thankfully all the included tools will now properly split those  
forks when placing the files on non-HFS mountpoints).

What that means... future support of Venti on OSX w/ P9US.

jas