[OpenAFS] Re: MacOS AppleDouble excretions

Jeffrey Altman jaltman@secure-endpoints.com
Thu, 21 Oct 2010 19:00:58 -0400

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 10/21/2010 6:30 PM, Adam Megacz wrote:
> Derrick Brashear <shadow@gmail.com> writes:
>> POSIX extended attributes are stored in the files. Until we deal with
>> them natively (which requires new RPCs) deleting them actively loses
>> data.
> Look, this fuss about "losing data" is a real distraction; can we handl=
> it and stick to the important issues?
> An error code should ALWAYS be returned to the userspace application by=

> a write operation if the AFS client has declined to perform that action=

> due to end-user configuration choices.  I don't think anybody in their
> right mind (or on this list) is proposing that the resource forks be
> silently discarded.  I think I was pretty clear about this in my
> original post.  Construing my proposal as "discarding" the forks is not=

> helpful at all, and muddies the issue a lot.
> If the filesystem reports an error, it has not taken responsibility for=

> the data, so it does not "actively lose[s] data".

The file system has already returned the error.  The operating system
has in turn decided to address the error by creating the alternate data
store (the double file) in order to avoid losing the data that the
application is writing.  To refuse to create the file will result in the
loss of data since the applications will be unable to save it.

MacOS X application expect that all file systems (this is a requirement)
have the ability to store extended attributes.   Permitting the data
stream to be stored and blocking all attempts to store the extended
attributes will not be a case that application developers are coding to
handle.  As a result it will likely lead to the same sort of application
instability as when Microsoft recently issued its MS10-020 security

When APIs that are never expected to fail do so, bad things happen and
it is extremely hard to track down the cause of the problem.  Consider
the case of an application that stores extended attributes, doesn't
check the return code because it should always succeed, and later
misbehaves because the data was never written and therefore can't be
read back in from the file.

I would be opposed to any option being committed to OpenAFS that is
likely to lead to unexpected application instability and increased help
desk calls even if the option is off by default.  Off by default means
the code is not going to be tested in future releases and can only
result in something worse happening down the road.

> Jeffrey Altman <jaltman@secure-endpoints.com> writes:
>> The fix for the I don't like DoubleFiles issue is to find the financia=
>> or development resources necessary to implement support for EAs
> I agree, although that is "a fix", not "the fix".
> I don't have access to those kind of resources, but I do have sufficien=
> resources to add the client-side option.

You may not have access to the necessary resources but others on this
list might.

Jeffrey Altman

Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

Version: GnuPG v1.4.9 (MingW32)