[OpenAFS] Re: MacOS AppleDouble excretions

[Jeffrey Altman]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig68BD3887C92694E9819F834F
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.
>=20
> Look, this fuss about "losing data" is a real distraction; can we handl=
e
> it and stick to the important issues?
>=20
> 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.
>=20
> 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
enhancement.

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=
l
>> or development resources necessary to implement support for EAs
>=20
> I agree, although that is "a fix", not "the fix".
>=20
> I don't have access to those kind of resources, but I do have sufficien=
t
> resources to add the client-side option.

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

Jeffrey Altman


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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iQEcBAEBAgAGBQJMwMYsAAoJENxm1CNJffh4XFEH/R+8UqAEeqjga0WFfp1asZys
tnyirVi7fN+NCh0W6n9k7jLNlp0SrVtkizBCR/R4XdshFK/ZQG8GbUuwWSy2p8VH
8Cvl5WSiYJ7JoCFgbYLH2NmT8DQ0Vln51mguHs6qIp4TDVdIS3eVlgw9Ey5UwSYF
ViyVCZApKuCdupIckQLmIz39Ke2RjyKMBdHij1Cqslt4+5/6dQyJGu9icaGIeSE6
ZegGook50X7eiICBF7oOwQZk9AswMSKaQdLVE2aFxB0T2RcHqnwlOFinmtxmn9e4
JMEoX1z3sducdylPxItKLXfNYTTgHCnD/baj820Ka/GQ3wa6GVbcO2dNd176zI0=
=kJTy
-----END PGP SIGNATURE-----

--------------enig68BD3887C92694E9819F834F--