From mboxrd@z Thu Jan 1 00:00:00 1970 Mime-Version: 1.0 (Apple Message framework v734) In-Reply-To: <20051011072551.GH8153@server4.lensbuddy.com> References: <4349E6B7.20008@lanl.gov> <20051011015640.5EEA91AB1BD@dexter-peak.quanstro.net> <20051011024950.GB28444@localhost.localdomain> <3e1162e60510102252y6e10ca4ejb50e6db1897cb697@mail.gmail.com> <20051011072551.GH8153@server4.lensbuddy.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Jeff Sickel Subject: Re: [9fans] [Fwd: road sign] Date: Wed, 12 Oct 2005 21:09:17 -0500 To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Topicbox-Message-UUID: 9a1f0d6a-ead0-11e9-9d60-3106f5b1d025 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