Subject: Re: How to fix CRLF stuff...

From: Peter DiCamillo <[email-masked]>
Date: Wed, 14 Feb 2001 17:35:09 -0500

Jeremy Buchmann wrote:
>  > Peter DiCamillo:
>>  2. When afpd creates a new file, the suppress translation bit is set
>>  if the file is not translated at that time.
>
>Ok...but how does afpd know to translate the file?  This is the problem I'm
>talking about...it seems you're talking about the problem of keeping track
>of what has or has not been translated.
Yes, I'm talking about a much less ambitious change than most of the 
discussion has been about.  Afpd would decide whether or not to 
translate the file using the same rules as it does now.

>  > Peter DiCamillo:
>>  With this approach, a Mac user could use the Finder to copy a TEXT
>>  file to a netatalk volume and back again without the file changing,
>>  although it would not be translated for Unix users.
>
>This is how it works now unless you specifically set the crlf option in one
>of the config files...how has this changed anything?
What I'm describing is a change in how the crlf handling would be 
done when the option is set.  It would allow you to set the crlf 
option, but no longer get that kind of corruption.  You trade off the 
fact that files won't get translated for Unix users if they were 
written by "misbehaving" Mac applications that change the type to 
TEXT later.

>  > Peter DiCamillo:
>>  This would be
>>  compatible with a more comprehensive solution where afpd could be
>>  told to either translate or not translate a given file.  When the
>>  suppress bit is off, setting the file's type to TEXT would force
>>  translation, and would also be useful to the Mac user.
>
>Now I'm confused...how do we set the file's type to TEXT?  Isn't that the
>problem...as of OS 8, Finder doesn't set the type before copying?
I'm referring to writing the AppleDouble file.  In the AppleDouble 
file you can store 'TEXT' as the Mac file's type at the same time as 
you're modifying the suppress bit.

Peter

---

From: Donald Lee <[email-masked]>
Date: Sat, 17 Feb 2001 01:28:22 -0600

I want to counsel caution on this feature.

One vital design element is simplicity, because data integrity
is pretty important, and testing is hard.  Complexity invariably
introduces errors, both in the code and in operation.

The schemes that I am seeing pass by are not simple and elegant.
They introduce multiple passes on the data, special flag bits, special
handling for upgrades, asynchronous processes etc, etc.

Be careful out there.  Make certain that the cure is not
worse than the disease.

-dgl-