Subject: Re: [netatalk-admins] FreeBSD 2.2.7 - stable - and netatalkstrange problems bypassSTGspamstuff.

From: Capriotti <[email-masked]>
Date: Fri, 09 Oct 1998 09:31:07 -0300

At 02:20 PM 10/9/98 +0200, you wrote:
>Hi again!
>
>OK.. Could it be that there is a CR/LF translation. 

.       BINA    UNIX

As far as I know, this should turn translation off for unknown files.

And, If I comment all the lines on AppleVolumes.system.default, all files
would be unknown, therefore, no files should be be cr <-> lf translated.

Is that correct ?

I believe it's on on
>by default, but I'm not sure. Should only happen on files with type
>TEXT, though... Perhaps it is a permission issue? But then you said that
>you had problems on windows too... Hmmm.. Sorry, I've run out of ideas.
>:-(
>
>/Palle
>
>
>Capriotti wrote:
>> 
>> At 04:07 AM 10/9/98 +0200, you wrote:
>> >Hello!
>> >
>> >I have an idea. Do all the problem files contain non-ascii characters in
>> >their names.
>> 
>> No, actually I thik I didn't completly describe the problem.
>> 
>> The files have normal ASCII names (I use to pay attention to this since
>> latin characters are also not very welcome to Windows machines);
>> 
>> What happens is that, in Photoshop for instance, the file starts loading
>> normaly, and after a while, photoshop stops loading, claiming that there is
>> an unexpected enf of file in the file.
>> 
>> Another situation: A file is Unziped on the PC, and Mac won't open it. Even
>> if you open it on the PC and save it under another name or format, it won't
>> opne.
>> 
>> It sounds absurd, but that's what happens.
>> 
>> I will double check on the file name thing, as soon as I can contact the
>> customer (It's a bit early here).
>> 
>> Depending on the result, I'll be asking you to send me your patches.
>> 
>> Thank you.
>> 
>>  Do the ones that work contain only ascii? My guess is yes.
>> >If you check the bad files on the unix machine, they will colons (':')
>> >in their names. Netatalk stores non-ascii character (and '/') as ':xx'
>> >where xx is the hexadecimal representation. Not very compatible  :-(
>> >
>> >Colon is not preferred by windos. They hate it ;-) Thus, the files won't
>> >show up.
>> >
>> >I did some work on this a while ago, and if you have a fresh system
>> >(i.e. not many files copied to the shared volume) you could try my
>> >patches. They make netatalk store filnames in iso-latin (8859-1) instead
>> >of MacRoman. This is good if you collaborate with Samba, since samba can
>> >also be set to this option.
>> >
>> >The original ones were supplied around new year (1998-01-02 or so?). If
>> >you're interrested, I could send you a ready made port for FreeBSD on
>> >the latest netatalk+asun appleshare/ip package. I haven't supplied it
>> >public yet, because I haven't had the opportunity to test it. I can send
>> >you patches tomorrow from work. Please mail me to confirm that the above
>> >is indeed the source of the problem.
>> >
>> >Regards,
>> >Palle
>> >
>> >Capriotti wrote:
>> >>
>> >> Hello. I am a newcomer, that has just finished borwsing the list
archives
>> >> of 1998 w/o great success to the problems found.
>> >>
>> >> The situation:
>> >>
>> >> P166 64 MB ram
>> >> FreeBSD 2.2-stable of october/1998 (first week)
>> >> netatelk 1.4b2 - precompiled package added to the out-of-the-box system
>> >> new kernel custom built to support appletalk.
>> >> Samba
>> >>
>> >> The problem:
>> >>
>> >> When I copy a file from a MAc station, from it's SCSI external Zip
Drive, I
>> >> get an appearently corrupted file.
>> >>
>> >> I say it is apearently corrupted because it will not open on any of the
>> >> PCs, w/ Win95 or 98. but it will still open in the Macs.
>> >>
>> >> The contrary is often true: Files compressed using Winzip, when inflated
>> >> will not open in the Macs.
>> >>
>> >> note that it does NOT HAPPEN with ALL hte files. Only SOME of the files
>> >> suffer of this.
>> >>
>> >> I tryed changing the Mac's Os version from 8 to 7.5.x, but it was of no
>> >> help. The MAc where the Zip is connected does not have the iomega
>> >> extension; It has a guest file from iomega, similar to PCs.
>> >>
>> >> I am clueless
>> >>
>> >> Any hints ?
>> >>
>> >> TIA.
>> >
>> >
>
>

---

From: Rob Newberry <[email-masked]>
Date: Fri, 9 Oct 1998 10:04:37 -0500 (EST)

> would be unknown, therefore, no files should be be cr <-> lf translated.

That is not completely correct.  The extension mapping only protects files
which do not have a Macintosh type/creator code.  If you have a file which
is type "TEXT", and netatalk has been built with CRLF conversion at
compile time, then it WILL perform conversion on that file no matter what
your AppleVolumes.* file says.

I've always wished that netatalk would have an option to control CRLF at
runtime (as an argument to "afpd") or even better, on a volume-by-volume
basis (as an option in the AppleVolumes.*) file.  I've actually written
patches which do this, but the maintainers didn't seem to want them --
they never replied to my inquiries.  No big deal -- I've got them for
myself.  Perhaps I'll revisit them and approach asun about it...

Rob

---

From: Tony & <[email-masked]>
Date: Fri, 9 Oct 1998 09:24:36 -0500

> myself.  Perhaps I'll revisit them and approach asun about it...

	Please do.
	I should also submit my patches for "fascist" restriction against
user-controlled Applevolumes files.  There are just too many environments
where control like that is a political necessity.
-- 
Anthony J. Stuckey                              [email-masked]
"When I was young, the sky was filled with stars.
 I watched them burn out one by one."  -Warren Zevon