From owner-freebsd-fs@FreeBSD.ORG Sat Apr 16 01:23:39 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 BA0E4106566C for ; Sat, 16 Apr 2011 01:23:39 +0000 (UTC) (envelope-from dan@3geeks.org) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7D5928FC18 for ; Sat, 16 Apr 2011 01:23:39 +0000 (UTC) Received: by ywf7 with SMTP id 7so486222ywf.13 for ; Fri, 15 Apr 2011 18:23:38 -0700 (PDT) Received: by 10.90.183.18 with SMTP id g18mr2960823agf.73.1302917017546; Fri, 15 Apr 2011 18:23:37 -0700 (PDT) Received: from [10.0.1.240] (99-126-192-237.lightspeed.austtx.sbcglobal.net [99.126.192.237]) by mx.google.com with ESMTPS id 6sm3124030anx.46.2011.04.15.18.23.35 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 15 Apr 2011 18:23:36 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Daniel Mayfield In-Reply-To: <20110416003306.GA13853@icarus.home.lan> Date: Fri, 15 Apr 2011 20:23:34 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1A369F02-452C-4812-A461-C9A4748AC340@3geeks.org> References: <20110416000112.GA13487@icarus.home.lan> <337FAD9E-6973-4CA4-96E2-4A24F69916AF@3geeks.org> <20110416003306.GA13853@icarus.home.lan> To: Jeremy Chadwick X-Mailer: Apple Mail (2.1084) 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 01:23:39 -0000 >>>> rsync: rsync_xal_set: = lsetxattr("Documents/","com.apple.ResourceFork") failed: No space = left on device (28) >>>=20 >>> 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. >>=20 >> 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. >=20 > 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. >=20 > 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? >=20 > 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. Rsync sees it as an extended attribute, a black box as it were, and = simply copies it byte for byte to the remote side which then attempts to = store the (very large) extended attribute. That's where the above = message comes from (rsync : "." . on the freebsd box is what is = emitting the no space left message). I fully admit that its a bit of a hack, but I'm just looking for a place = to start within the code so I can try to allow for arbitrarily sized = extended attributes (or at least allocate an inode for large extattrs). = Google gives me this: = http://lists.samba.org/archive/rsync/2009-October/024124.html which = confirms that the size limit of the extattr is to blame. The poster = there had a similar idea to what you described, but I'm not satisfied = with that. daniel=