[OpenAFS] Re: MacOS AppleDouble excretions

[Derrick Brashear]

I'll echo this. While I think jeff paints an overly dire picture, if you =
are so hard up that you need to throw away data (no, it's not a lark. =
You want to discard data. It's fine, but I feel no compunction to be =
helpful) can I suggest a cron job, a dot file, pretty much anything =
other than handing out a gun that shoots a cosmetic problem with ugly =
side effects?

Derrick

On Oct 21, 2010, at 7:02 PM, Jeffrey Altman =
<jaltman@secure-endpoints.com> wrote:

> 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 =
handle
>> 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".
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
>> Jeffrey Altman <jaltman@secure-endpoints.com> writes:
>>> The fix for the I don't like DoubleFiles issue is to find the =
financial
>>> 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 =
sufficient
>> resources to add the client-side option.
>=20
> You may not have access to the necessary resources but others on this
> list might.
>=20
> Jeffrey Altman
>=20