Subject: Re: [netatalk-admins] netatalk+asun and Samba bypassSTGspamstuff.
From: PayPC System Mail Subscriber (spammail@quanta.paypc.com)
Date: Thu Oct 29 1998 - 21:45:55 EST
Glenn said in Re: [netatalk-admins] netatalk+asun and Samba
bypassSTGspamstuff. at 30/Oct/1998 (Fri) 05:54:54.
> I have a similar thing happening - files created by my linux gimp can be
> open by mac software, though all works fine in opposite direction. If I open
> files and resave with Windows it _seems_ to fix problem.
> Glenn
>
Hrm, I guess I've been lucky (or I setup things correctly)... but I don't
have any file translation issues, EXCEPT for text files (more later). BTW, I
recommend you setup PDF files as "PDF " "CARO" *NOT* the normal TEXT/CARO....
many PDFs are not TEXT, and in my experiences of dealing with hundreds of
web-borne (as well as locally generated (Distiller) PDF files, even the text
ones are OK if treated as "binary" types.
Anyhow, my text file issues are follows: I have samba/mac/linux shared
zones..... I'll summarise with a Matrix:
Creator
UNIX + MAC + SAMBA/PC
Accessor +----------------------------
UNIX ! OK OK MAYBE(2)
MAC ! OK OK NEVER(3)
SAMBA/PC ! MAYBE(1) MAYBE(1) OK
(1) Most programming editors (PFE, say) are tolerant of alternate platform
text line ends. Most "dumb" DOS tools can't deal with it. I'm not that
worried about this "dysfunction".
(2) This one is also pretty minor... Most unix tools seems to ignore the
extra character, though some display the CR as ^M (some text editors do) --
others like joe happily munch them silently.
(3) This is the annoying one. ALWAYS end up with double-spaced text when
accessing PC-created text objects. This would be a minor annoyance at
best... EXCEPT I happed to use CSV (Excel-type command-separated-values),
which gets a bit damaged in the translation (well, not data-loss damaged, but
annoying "double-spaced" spreadsheets, which most of my users require a
person like me to "undo").
The long and short of it is that MAC<->UNIX, things are pretty happy. It's
when you have SAMBA/PCs into the mix, the shit hits the fan. (Isn't that
always the case?)
I know the problem is this: PC's use CR/LF, and the translation in
netatalk+asun only converts the LF->CR... which leads to the double-spacing I
observe - that's not rocket science. I also know where the translation code
is performed - but I have a worry/question... what if I 'eat' the LF of a
detected CRLF pair (just passing CR's unmodified) in a text file stream? I
worry because the file advertises itself as say, 2000 bytes, but in actual
fact would be "smaller" because of the eaten LF's. Replacing it with a NUL
isn't the right approach either, because some apps go psycho when binary-like
data is encountered in an otherwise ASCII stream.
I'd be more game to try this live, except my server environment is a
production one with nearly 100% utilisation at all hours. :( If I broke
something in my tests, I'd have many whinging users at my door. I'd be
willing to experiment if my idea seems sound to netatalk gods (Adrian, your
comments?)
Note that tools like BBEdit merrily munch anyone's text file format very
happily... it's just that not all of my Mac users are geekheads who have (or
need, really) BBEdit on their machines. Tools like Simpletext aren't so
smart. And then there are tools like Excel, etc, which assume text formats
are in native Macintosh style.
Oy. It's 1998 and we're still battling over text files. :)
=Rob=
PS: I have work-arounds, of course. Namely, telling my users to not use .csv
as the file extension for CSV files generated on the PC.
PPS: Also, I'd *STILL* like a way to disable .AppleDouble creation entirely.
I know most things aren't affected by the presence of those directories,
but... I use IMAP4r1 almost exclusively for mail... and I get tons of Poo all
over my mail directories (.parent, .AppleDouble, etc) the worst thing about
it is they have the same names as my real folders (just under the
.AppleDouble dirs), so some of my users get confused and click on the
.AppleDouble mail folders instead of the "real" ones (of course, this
generates a nasty little client error message about invalid mailbox,
blahblah) (oy, the troubled life of a BOFH!)
Anyhow. Again, I have a workaround - many Macintosh users use Maildrop, so
I've setup regex ignore patterns, and with my PC (and Macintosh) Outlook
Express users, I tell them to manually subscribe to the real mail folders,
and to configure the client to not display unsubscribed folders. Fortunately
and amazingly enough, this works for both platforms of Outlook Express
(Mac/Windoze) as well as Maildrop! - WOW somebody got their shit together for
that! That is, you configure it (with one client) and the rest "pick up" the
configuration (aside from the "not display unsubscribed folder option, which
is just a simple checkbox.
Anyway... this e-mail has gone for far too long...
=Rob=
This archive was generated by hypermail 2b28 : Sat Dec 18 1999 - 16:33:38 EST