From owner-freebsd-fs@FreeBSD.ORG Sat Apr 16 00:33:08 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 577D41065672 for ; Sat, 16 Apr 2011 00:33:08 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by mx1.freebsd.org (Postfix) with ESMTP id 3D1BE8FC0C for ; Sat, 16 Apr 2011 00:33:07 +0000 (UTC) Received: from omta03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by qmta06.emeryville.ca.mail.comcast.net with comcast id Y0Gf1g0030b6N64A60Z7Vo; Sat, 16 Apr 2011 00:33:07 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta03.emeryville.ca.mail.comcast.net with comcast id Y0Z61g00i1t3BNj8P0Z7jD; Sat, 16 Apr 2011 00:33:07 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id AB6169B42B; Fri, 15 Apr 2011 17:33:06 -0700 (PDT) Date: Fri, 15 Apr 2011 17:33:06 -0700 From: Jeremy Chadwick To: Daniel Mayfield Message-ID: <20110416003306.GA13853@icarus.home.lan> References: <20110416000112.GA13487@icarus.home.lan> <337FAD9E-6973-4CA4-96E2-4A24F69916AF@3geeks.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <337FAD9E-6973-4CA4-96E2-4A24F69916AF@3geeks.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@freebsd.org Subject: Re: question on extended attributes X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 00:33:08 -0000 On Fri, Apr 15, 2011 at 07:06:40PM -0500, Daniel Mayfield wrote: > > On Apr 15, 2011, at 7:01 PM, Jeremy Chadwick wrote: > > > On Fri, Apr 15, 2011 at 05:01:58PM -0500, Daniel Mayfield wrote: > >> I'm trying to use rsync and rsnapshot to make backup copies of my Mac to my freebsd 8.2 server . When I specify syncing extended attributes as well, I get an error for any file on the Mac that has a resource fork: > >> > >> rsync: rsync_xal_set: lsetxattr("Documents/","com.apple.ResourceFork") failed: No space left on device (28) > >> > >> I'd love to work on fixing this, but I'm seeing a bunch of references to UFS1 vs UFS2 in the extended attribute readme. But I'm not sure what I'm actually using (I took the default when it setup, which says ufs2+softdep, but mount simply says ufs). > >> > >> Can someone help point me in the right direction? > > > > Sorry if this sounds harsh or rude, but can I ask you what exactly > > extended filesystem attributes (usually ACLs) have to do with file > > resource forks on OS X? AFAIK they have nothing to do with one another. > > OS X stores resource forks (and a few other things) as extended attributes on HFS+ filesystems these days. Or at least that's how it presents the HFS+ concept of a resource fork to unix programs like rsync that understand extended attributes. I'll assume you're right. With that assumption in place: OS X rsync supports extended attributes, which when used (on an OS X client) reads data from HFS+ extattr. How exactly do you expect this data to be saved on a non-HFS+ filesystem, such as BSD FFS/UFS, or Linux ext2fs, or Solaris UFS? How will rsync (on the server side, meaning the process that's actually writing the data to a file on the filesystem) know what to do with this data? The only way this would be possible is if rsync had its own custom way of saving resource forks on a remote system (they would have to be separate files). Restoration would require that rsync know what to do with some "specially-named files" to represent the resource fork portion. Keep reading for an example. > > Also, you're aware of how Apple solved the resource fork problem when > > archiving something in a .zip file, right? The "_MACOSX" directory > > within the .zip. > > This is sub optimal as I'd like to be able to inspect/modify the "data fork" of the file on the freebsd box too. For example, editing files while I'm ssh'd into the freebsd machine remotely, but still preserving the icon when it gets copied back. If I were to do as you described, I may as well setup netatalk and build a time machine style backup device. That isn't my goal. Resource forks are a pain in the ass and have been for the past 20 years: again, they existed on the Apple IIGS (which used either ProDOS or HFS filesystems), and the only thing that supported them aside from the filesystem and OS itself was -- ding ding -- ShrinkIt (.shk). It amazes me that Apple continues to use them. How do they work when you format your OS X filesystems as FFS? I'm sure Apple has some kludge there for it. History lesson with validations: The Apple IIGS (specifically GS/OS) had support for resource forks. The only thing that could use them was GS/OS. You could use GS ShrinkIt to save/archive something with resource forks, and it would pop up a dialog warning you of the repercussions if you tried to restore/extract it on a non-GS/OS (e.g. PC, and sometimes Macintosh) machine. If you were using standard ShrinkIt (ProDOS), there was no support for resource forks. So guess how Andy McFadden -- famous Apple II programmer -- solved this problem with the multi-platform nulib archiver? If a resource fork is encountered in a .shk (ShrinkIt) file, and the platform you're restoring on is non-GS/OS, the resource fork portion is stored as a *separate file* with "_rsrc_" appended to the filename. Apple has effectively done the exact same thing with .zip and the _MACOSX directory. rsync would need to mimic that functionality to ensure cross-platform compatibility (storage and retrieval of resource forks). -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB |