[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[no subject]
No, pine is handling the MIME/base64 decoding just fine (uuencoding is not
involved) - but there may be a problem. I need some unix (AIX, or HPUX, or
DomainOS - I can use three different machines, accounts). I may have
discovered the problem.
I took a CC: attachement file from my boss'es PPC7200 which opens OK in
Word and copied it to a HFS disk. I opened the same mail on my AIX pine
system and extracted the attachment file. I downloaded this file to my
IIGS harddrive (ProDOS) with PT3.1 and zmodem. Then under GSOS (6.0.1) I
used Bill Tudor's File Compare finder extra to compare the two files.
Some things were expected, like the resource fork on the Mac extracted file.
Pine/GS-PT3 EudoraPro/Mac
Filetype $0006 $0000
Auxtype $00000000 $00000000
Access $00E3 $00E3
storType $0002 $0005
(Date and ModDate are different because the files were extracted/downloaded
on different dates (Apr 13 vs Apr 5)
DateSize $00004E00 $00004E00
Res Size $00000000 $0000011E
Ok, file info differs but is what I expect. Now, compare DATA FORK ...
$0000: 04 00 00 09 04 ... 00 04 00 00 09 04 ...
The Mac file has ONE extra leading byte. The entire file is identical but
the Apple II file is shifted ONE byte left toward the origin throughout.
I need some unix help. How can I look at a hex dump of a unix file to see
if the extra byte was there before I downloaded the file (ie, it was lost
by pine and not the Apple II). My next experiment will be to prepend a 00 to
a downloaded file and see if Word will correctly recognize that file.
I appreciate the feedback from supertimer and Nick. I agree with Nick that
one helpful thing would be for my Texas boss to change his e-mail method,
but really ... This is a Boss, he doesn't have a problem - I have a problem!
Sort of demands a different solution. ;-)
Have a productive day!
--Steve
--
--Steve (apple2pd@ground.ecn.uiowa.edu)