[OpenAFS] Re: MacOS AppleDouble excretions
Thu, 21 Oct 2010 19:29:56 -0400
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 =
On Oct 21, 2010, at 7:02 PM, Jeffrey Altman =
> On 10/21/2010 6:30 PM, Adam Megacz wrote:
>> Derrick Brashear <firstname.lastname@example.org> writes:
>>> POSIX extended attributes are stored in the files. Until we deal =
>>> them natively (which requires new RPCs) deleting them actively loses
>> Look, this fuss about "losing data" is a real distraction; can we =
>> it and stick to the important issues?
>> An error code should ALWAYS be returned to the userspace application =
>> a write operation if the AFS client has declined to perform that =
>> due to end-user configuration choices. I don't think anybody in =
>> 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 =
>> helpful at all, and muddies the issue a lot.
>> If the filesystem reports an error, it has not taken responsibility =
>> 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 =
> 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 =
> loss of data since the applications will be unable to save it.
> MacOS X application expect that all file systems (this is a =
> 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 =
> handle. As a result it will likely lead to the same sort of =
> 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 =
> 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 <email@example.com> writes:
>>> The fix for the I don't like DoubleFiles issue is to find the =
>>> 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 =
>> resources to add the client-side option.
> You may not have access to the necessary resources but others on this
> list might.
> Jeffrey Altman