Subject: Re: How to fix CRLF stuff...
From: Duncan Sinclair (sinclair@dis.strath.ac.uk)
Date: Tue Feb 13 2001 - 10:29:52 EST
Hi,
Bob Rogers writes:
> From: Duncan Sinclair <sinclair@dis.strath.ac.uk>
> Date: Sat, 10 Feb 2001 17:08:46 +0000
>
> . . .
>
> 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.
> 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.
>
>Since the original motivation was to make Mac files usable to Unix
>apps/users, using the sticky bit seems like asking for trouble. If the
>files are only accessed from Macs via shares, then you can guarantee
>that no Unix apps will misinterpret or change their sticky bits. But in
>the general case, it seems safer to use the .AppleDouble file . . .
OK, I've done some reading up and the sticky bit is out, but maybe
there is some combination of 'x' bits that could be used. I'm not
100% sure if netatalk uses the exec bits to mean anything (it doesn't
look like it, but I don't fully understand what afpd/unix.c does with
modes), but I was thinking that maybe "g-x,o+x" might be a good flag.
> 1. If some other Unix app were to edit the file, would it preserve
>"+t"? (emacs 20.7 does, btw.) How about some random Windows app (via
>Samba)?
Unix apps should preserve mode bits. I don't know if samba does this.
>From a quick glance it seems to do something with at least the u+x bit,
but I can't see any particular pattern.
> 2. Also, if some other bit were used on a different netatalk port
>due to system constraints, then you wouldn't be able to move shares
>between the two systems via Unix means (e.g. dump/restore, tar).
Yep, well life's like that. With the "g-x,o+x" solution, this should
be portable between all posix compliant systems, unless they are playing
tricks...
> 3. There is also a compatibility issue here. After installing a
>hypothetical new version of netatalk that uses this explicit
>transformation indication, there will be transformed files without the
>sticky bit, and possibly untransformed "+t" files.
Yep, an "upgrade" step would be needed, along the lines of what you
suggest.
>This is the same marking operation as when a newly Unix-created file is
>first seen by afpd, and could be as simple as "chmod +t" . . . but
>somehow it feels safer to me to keep it in the .AppleDouble file . . .
Emm... How about in both places. With either being used, probably
using the mode bits first for speed.
> 4. Also, how does this interact with the "noadouble" feature? It
>seems to me that if "lazy" .AppleDouble creation is enabled, then the
>server would always have to create an .AppleDouble file for text files,
>just to tell itself in the future that the "+t" bit is significant.
Not sure. I don't use "noadouble", so don't know its implications.
I guess though that "noadouble" would be mostly used in non-Mac areas.
(My motivation is to allow manipulation of Mac files on Unix, not Unix
files on Mac, so I would rarely point netatalk at a "Unix" directory.)
Perhaps "noadouble" should imply "nocrlf", or at least no mode bit
twiddling. If a "noadouble" area is unix only, it should use the
traditional AppleVolumes.system way of deciding if it wants to do cr/lf
conversion.
Is "noadouble" lazy, or completely prohibitive?
>In addition to automatic transformation, it would be good to have a Unix
>utility, call it afpd-xlate-crlf, that can do the transformation and
>update the appropriate bit on demand.
Good idea.
>That would help for the ambiguous
>and/or misleading cases (as long as the daemon continues to obey the
>bit, regardless of what the file type says).
Hmmm... If you over-wrote a text file with a binary file, I wouldn't
want it to continue doing cr/lf munging. But then my helper process
would sort out the move from text to binary as well as binary to text.
> But, to be safe, such a program should do file locking to avoid
>corruption, since it has to update both the data and the bit. Which
>makes it seem a bit like your proposed helper app. Maybe afpd should
>spawn afpd-xlate-crlf to do these translations on the side?
Excellent idea. You might choose to you the same binary for the helper
app, for the manual process, and for the "upgrade" step...
>The locking
>should give you all the serialization you need (as long as you avoid
>race conditions between afpd and afpd-xlate-crlf). But if you do
>translate asynchronously, you still have the problem that you can't
>return an error to the client if afpd-xlate-crlf fails. And maybe,
>after all is said and done, translation isn't such a big job that it's
>worth the overhead of forking a new process . . .
One reason for serialising the operation is to avoid forking several
hundred processes as a result of the Finder copying a large number of
text files and changing their types quickly.
Thanks for your comments!
Cheers,
Duncan.
This archive was generated by hypermail 2b28 : Sun Oct 14 2001 - 03:04:32 EDT