In article <1992Jul31.163029.14339@pool.info.sunyit.edu> ujlh@pool.info.sunyit.edu (James Henrickson) writes:
quoted text
>In article <1992Jul30.175218.26142@ifi.uio.no> janl@ifi.uio.no (Jan Nicolai Langfeldt) writes:
>>In article <Bs5tqK.BMr@ux1.cso.uiuc.edu>, Upholder@uiuc.edu (THE Upholder of Truth) writes:
>>> for example, issuing a 'compress vixie-cron.tar' results in an error message
>>> that a .Z could not be appended because the filename was already 14 characters.
>>
>>Max filename length is a compile time constant, so you have to edit
>>the right .h file(s) and recompile.
>>
>
>Maybe I'm missing something, but shouldn't it be a macro that expands to
>a system call?  That way it wouldn't be a compile-time constant and a
>program would be more able to adapt to different file systems.  Of course,
>allocating an array based on one file system and using it for a larger
>file system would result in some strange behavior.  :(

I don't know of any system that will give you the max filename length
via a system call.

For 'compress', which is the program being discussed, the problem is
inherent to compress - the max filename length of 14 characters is
defined in the program itself.  You need to edit the compress source
where that check is done, and fix it to use a value other than 12,
which is how it is coded.  (That is, if the filename is greater than
12 characters, it gives that message.)

The 0.97 root disk (a day or two away) will have a compress that will
accept 253-character filenames to add .Z to.  Note that this could
cause some problems with 14 character filenames on Minix filesystems.
-- 
                                    +    Jim Winstead Jr. (CSci '95)
                                    |            Harvey Mudd College
                                    | jwinstea@jarthur.Claremont.EDU
                                    + This is all my words.  Honest!