Subject: Re: CRLF fun stuff again...
From: Steve Freitas (sflist@ihonk.com)
Date: Sat Feb 10 2001 - 05:12:06 EST
Hi.
> What Samba does is of no great consequence to me. But I will say
> that Windows' CR&LF at least allows files to be manipulated
> fairly easy on the Unix side.
Duncan, I think the point of mentioning Samba's design is related to the
credibility of their approach. That is, some Very Smart People designed
Samba, and Samba is vastly more widely deployed in production use than
Netatalk. Therefore, there is a high probability that their designs are
correct for the majority of users. This is an issue for all cross-platform
file servers, and their conclusion carries heavy credibility.
>> I think that is absolutely the right thing to do. I've had this CR/LF thing
>> munge up whole ISOs for me, even when it's turned off.
>
> How????
I detailed this in earlier posts. I'm using 1.5pre3 from Mac OS 8.6. The
short version, if I can remember correctly:
1. I had no CR/LF enabled for the share. Other config files were as default.
2. I took a file on the Mac, duplicated it and gave the files these two
names: "test.iso" and "test.jpg".
3. I checksummed both files on the Mac, then copied them to the Netatalk
volume. I then checksummed them again on the Linux box. Test.jpg was
unchanged, while test.iso had changed.
4. I added a .iso entry to AppleVolumes.system, and that solved it for .iso.
(Disclaimer: This was a while ago and very convoluted, so for the actual
results, check the archives. My mail blew up a few weeks ago and I've lost
all my archives, so I can't refer you to it.)
>> When you've got to remember to add a line to AppleVolumes.system just to
>> keep a file with a new suffix from being corrupted, that's just bad.
>
> Doesn't cr/lf need to be explicitly turned on the in the options
> for the share? But maybe the default AppleVolumes.system wants
> to be changed too. My AppleVolumes.system file has commentary on
> this issue that doesn't seem to be in the current version:
I don't know... I discussed it with the list, but everybody I talked to
seemed to think that CR/LF was off, and in fact when I explicitly tested its
functionality, it was off. However, Netatalk was definitely fiddling with my
ISO and corrupting it through linefeeds, and my experimentation showed that.
> I'll repeat again my position: if netatalk is going to have this
> feature, and there's evidence that people want it, then it should
> work properly. People who don't want this feature should be
> unaffected by it.
If it's possible for it to work properly, I agree. However, my concern is
that Netatalk's default configuration (1.5prex) currently permits corruption
of binaries, and I think all CR/LF ought to be disabled by default.
Steve
This archive was generated by hypermail 2b28 : Sun Oct 14 2001 - 03:04:32 EDT