macauslandr@watt.ccs.tuns.ca (05/28/91)
I'm having a bit of a problem with files I've been downloading from
ab20. Every file (with the exception of .LZH's) I've tried so far has resulted
in the message 'File is not an object module', after it has been unpacked
(the file has the correct protection bits set). This problem does not occur
with .LZH files however for some reason. I have a feeling that something
peculiar is going on... can anyone shed some light on this?
RM - Macauslandr@watt.ccs.tuns.ca
burton@latcs1.lat.oz.au (Jamez de Coilier) (05/28/91)
In <1991May27.165513.1@watt.ccs.tuns.ca>, I could have sworn macauslandr@watt.ccs.tuns.ca managed to say: >I'm having a bit of a problem with files I've been downloading from >ab20. Every file (with the exception of .LZH's) I've tried so far has resulted >in the message 'File is not an object module', after it has been unpacked >(the file has the correct protection bits set). This problem does not occur >with .LZH files however for some reason. I have a feeling that something >peculiar is going on... can anyone shed some light on this? If you are NOT using kermit, you might need to run FIXOBJ or equivalent on an executeable after transfer. This is because some protocols add padding bytes on the end of ... the file I suppose. Fixobj is a program which will fix this. There are many others. Kermit does not add padding bytes, but xmodem definately does. I don't know about ftp, or whatever. > >RM - Macauslandr@watt.ccs.tuns.ca > -- from the office of, James Burton. Latrobe University, Melbourne, Australia. Email burton@latcs1.lat.oz.au
pilgrim@daimi.aau.dk (Jakob G}rdsted) (05/29/91)
macauslandr@watt.ccs.tuns.ca writes: >I'm having a bit of a problem with files I've been downloading from >ab20. Every file (with the exception of .LZH's) I've tried so far has resulted >in the message 'File is not an object module', after it has been unpacked >(the file has the correct protection bits set). This problem does not occur >with .LZH files however for some reason. I have a feeling that something >peculiar is going on... can anyone shed some light on this? Well, this is only a suggestion - but have you checked if the execution flags are set? Sometimes/some systems does not support the Amiga File flag, so when you get home, only read flags is set. >RM - Macauslandr@watt.ccs.tuns.ca > -- From the notorious Jakob Gaardsted, Computer Science Department Bed og arbejd ! University of Aarhus, Jylland (!) (Pray and work!) AMIGA! pilgrim@daimi.aau.dk | I'd rather play Moria.
peraue@cs.vu.nl (Raue Paul Erik) (05/30/91)
burton@latcs1.lat.oz.au (Jamez de Coilier) writes: >In <1991May27.165513.1@watt.ccs.tuns.ca>, > I could have sworn macauslandr@watt.ccs.tuns.ca managed to say: >>I'm having a bit of a problem with files I've been downloading from >>ab20. Every file (with the exception of .LZH's) I've tried so far has resulted >>in the message 'File is not an object module', after it has been unpacked >>(the file has the correct protection bits set). This problem does not occur >>with .LZH files however for some reason. I have a feeling that something >>peculiar is going on... can anyone shed some light on this? > If you are NOT using kermit, you might need to run FIXOBJ or equivalent >on an executeable after transfer. This is because some protocols add padding >bytes on the end of ... the file I suppose. Fixobj is a program which will >fix this. There are many others. Kermit does not add padding bytes, but xmodem >definately does. I don't know about ftp, or whatever. Although this is true, XModem does add control-z at the end of the files, this doesn't affect any files that are not ready executable (which not many are on ab20). If you're using an archiver like zoo, it will just ignore the last control-z characters (probably) if not you have to strip these using a good text-editor/binary editor or write your own utility. However if the file unpacks alright it might be a good idea to look at the protection bits of the file. A normal executable file should have protection bits of ----rwed or --p-rwed. This means that the file is readable, writable executable and deletable (and optionally pure). If you're downloading zoo archives it might be that the protection bits are set to ----rw--, at least that is my problem. Just use the standard DOS protect command to remedy this and you shouldn't have any more problems. Hope this helps, Paul-Erik Raue (peraue@cs.vu.nl)