Subject: [netatalk-admins] Corrupt images... hrrrmmm...

From: Neil McAllister <[email-masked]>
Date: Wed, 30 Sep 1998 11:31:48 -0700

I've just recently (as in, yesterday) noticed some image corruption over a
netatalk server.  I have a script that uses the ImageMagick package to
convert files from other formats into JPEGs.  So the procedure goes like
this:

1.  Copy an image (say, a BMP) to a netatalk shared directory
2.  Run the conversion program to make it into a JPEG, on the Unix side
3.  Double click on the resulting JPEG.  It opens with Picture Viewer --
completely garbled looking.
4.  On the other hand -- fetch the file, using Netscape, by specifying an
URL to the file on the Unix server.  IT OPENS FINE.

Go figure.

So is this a problem with:
1.  The way netatalk transmits data?
2.  The way Linux stores data on the drive (and it isn't completely
translated by netatalk)?
3.  The way ImageMagick creates JPEGs (and Picture Viewer doesn't like it)?

I don't know.  But the bottom line is -- the images aren't corrupted.  Not
completely, anyway.  They just don't seem to want to be used "live" from
the server via netatalk.

--
Neil McAllister, Systems Administrator
Primo Angeli Inc., San Francisco, CA, USA
http://www.primo.com  mailto:[email-masked]

---

From: Patrick Herzog <[email-masked]>
Date: Thu, 01 Oct 1998 09:12:26 +0000

I can imagine this is a type/creator problem. Did you change the file name on
the unix side? If not, the Mac assumes that your newly created JPEG is still
BMP. And look garbled of course.

Try copy your image to nice.jpg on the unix side and test what it looks on the
mac.

Patrick

--
Dr.-Ing. Patrick Herzog
-- Oberingenieur --
RWTH Aachen
Institut für Technische Elektronik
Sommerfeldstraße 24
D-52056 Aachen, Germany
http://www.ite.rwth-aachen.de

---

From: Vivek <[email-masked]>
Date: Thu, 1 Oct 1998 11:34:09 +0100 (BST)

On Wed, 30 Sep 1998, Neil McAllister wrote:

[snip]
> 1.  Copy an image (say, a BMP) to a netatalk shared directory

Are you copying from a Mac or from another Unix directory? The first time
you access this file from a Mac, either to read or when you write to it,
netatalk will create its .AppleDouble file [the resource fork] with
type/creator info.

> 2.  Run the conversion program to make it into a JPEG, on the Unix side

Ok, you've changed the type of the file: Are you creating a new file, or
renaming the old one? It matters from a type/creator perspective: If its a
new file, you should be Ok, if it's the same one, I'm not sure - I don't
know if netatalk redoes the resource fork if you do a name change on a
file.

> completely garbled looking.

Hmm... could be one of two things:

1] Looks like your default translation is TEXT/UNIX or similar. Try
   setting the default translation to BINA/TTXT, and make sure the 'type'
   field for .jpg and .jpeg isn't 'TEXT'

2] The files type/creator info hasn't been updated, the Mac thinks it's
   still looking at a BMP.

> URL to the file on the Unix server.  IT OPENS FINE.

Yeah, this is it: when Netscape gets the file, it 

a) Won't do CR/LF translation
b) Will not fetch a resource fork, since http/ftp don't know about
   resource forks: If you're fetching it via ftp then the webserver will
   supply a mime-type from which the Mac will deduce the type/default
   creator info.

Have a peek at the resource fork of the .jpg file, make sure it's the
right type, and make sure you aren't getting unnecessary CRLF translation.

I can recommend setting the default to BINA/<something> and explicitly
setting only those types to TEXT that you _know_ need/want CRLF
translation even if this isn't you problem - saves a lot of trouble.

Vivek
-- 
It is easier to get forgiveness than permission.

---

From: Neil McAllister <[email-masked]>
Date: Thu, 1 Oct 1998 09:30:33 -0700

OK, for all the people who responded about my apparent JPEG corruption:

I never, never, never enable CRLF translation on my netatalk volumes.  As I
am the only user with shell-level access to the Linux machine, and I have
access to a text editor that's capable of doing Unix linefeeds, I don't
need it.

The thought about file type/creator is interesting.  But here is how you do
a conversion with ImageMagick, for instance:

%convert filename.gif filename.jpg

This takes a file name filename.gif and writes a NEW file, named filename.jpg.

Further, I am using MacOS 8.5, where File Exchange recognizes certain file
types of PC-format or other media.  So, even though the new JPEG file was
created entirely on the Unix server and does not inherently have any
resource fork, it shows up automatically with the QuickTime icon for "JPEG".

I suppose it could be that QuickTime's Picture Viewer is (erroneously)
trying to read resource information from the file based on how netatalk is
publishing its type/creator...

---

From: Vivek <[email-masked]>
Date: Fri, 2 Oct 1998 13:33:41 +0100 (BST)

> I never, never, never enable CRLF translation on my netatalk volumes.  As I

Fair enough.

[snip] 
> publishing its type/creator...

What type/creator is netatalk setting for the .jpg file? [they're 557
bytes in to the resource fork, iirc.]

-- 
If we all work together, we can totally disrupt the system.