Subject: How to fix CRLF stuff...
From: Duncan Sinclair (sinclair@dis.strath.ac.uk)
Date: Sat Feb 10 2001 - 12:08:46 EST
Hi,
Now that we've (hopefully) established that netatalk does do a
reversable transformation on text files as they are written and read
and doesn't corrupt files by design, I'd like to put forward my current
thoughts on how the actual bug could be fixed.
The problem is that text files created with a non-"TEXT" type and then
changed to have a "TEXT" type don't have the cr/lf transformation done
to them. This means then when they are served, because they are now
recognised as "TEXT", they will have an un-necessary cr/lf
transformation done to them.
Either the un-necessary transformation should be avoided, or else when
the type of a file is changed, a transformation should be done, if
needed.
I previously wrote:
Here's my proposed solution:
* A second "helper" process would run along side the main afpd process,
tied to it with pipes.
* tasks would be handed to it like "do a cr/lf transformation of this file".
* it would have to take care to lock files.
* tasks are done serially - to make sure nothing gets screwed.
* there may be other types of thing it could be used for.
As an additional safeguard, it may be wise to be able to mark files
which have had the cr/lf transformation done to them so that when
they are sent back to the Mac there is no chance of them being
messed up. In fact, this could be done without my proposed changes
above. Peter DiCamillo made a similar suggestion previously, and I
thank him for bringing it to my attention last week.
I would mark transformed files by setting one of the lesser-used mode
bits on the file. (This is similar to how the "XBITHACK" feature
works in Apache, and it may not surprise you to learn that I was the
inventor of this idea. (I didn't do the implementation however.))
So, what would happen is that when a transformation is done (either at
the time of writing the file, or by my "helper" process as a result
of a change of file type), one bit of the file's mode, say the sticky
bit, would be set on. If for any reason the file was changed to a
different type and so un-transformed, the sticky bit would be cleared.
When netatalk comes to serve the file, if it is a Mac file (complete
with AppleDouble info), then it would examine the sticky bit. If it is
set it would do the transformation as it serves the file. This would
ensure that it only re-transforms files which have already been
transformed.
On the unix side there is a clear indication that the file has had this
transformation - a nice bonus. Unix-created files would continue to
use the file extension to determine whether the file is text and want
transformed when served.
If for some reason the sticky bit was unavailable for use in this
fashion, berhaps a spare bit could be found inside the appledouble
info - but this wouldn't be as efficient.
Constructive criticism welcome. Offers of code even more so.
The more I deleop this idea, the closer it gets to being implemented.
The stuff about setting the mode bit could be done in an afternoon,
perhaps, if you knew your way around the code. The stuff about the
helper process would require greater effort, but could be worth it
in the opportunities for extra features it would give.
Thanks for your time.
Cheers,
Duncan.
This archive was generated by hypermail 2b28 : Sun Oct 14 2001 - 03:04:32 EDT