[MiNT] Long filenames (was: Pine hanging)

[Guido Flohr <gufl0000@stud.uni-sb.de>]

Hi!

Mario has reported that Pine hangs if the program accesses files
whose names access a certain limit.  This seems to be a general
problem.  For example Thing 1.01 refuses to read directories
if the names of the files inside exceed something of about
30 bytes.  The fileutils have related problems:

	# touch 0123456789012345678901234567890123456789
	# ls *
	ls: *: file not found
	# ls
	0123456789012345678901234567890123456789

???

I've started a little investigation on that.  The first problem
is the MiNTLib.  At least with patchlevel 46 there can be 
inconsistent values for the *_NAME_MAX macros in limits.h,
dirent.h and stdio.h.  If __MINT__ is defined the maximum
filename length supported by the library is 128, if __MINT__
isn't defined it is only 32.

Thus, you have to know if __MINT__ was defined at compile-time
of the library if you want to know which filename length it
supports.  This is illegal in my opinion.  If it hasn't been
fixed yet I would propose the following.  

In limits.h the macro _LIB_NAME_MAX should be replaced by
a global variable of the same name (or the macro should be
defined to the name of such a variable if you prefer).  

After browsing through some more #ifdefs you will also see
that the definition of struct dirent in dirent.h will also
require a modification.  The size of the array member d_name
needs to be a compile-time constant.  For TOS (without MiNT)
the remaining bytes are then redundant.

But I actually can't imagine that this is the real reason
of the above mentioned errors (because I can't imagine that
Thomas didn't #define __MINT__ when he compiled Thing).

I've taken a look then into dosdir.c of the kernel sources.
This looks sane to me.  The length argument of the Dreaddir
system call is passed unchanged to the callback of the
file system driver.  Hm, I currently don't have the sources
of minixfs.  Frank, could you have a look and tell us
what happens?

If you have typed the stuff at the top into your shell and 
now you don't know how to get rid of the file you
created:

	# rm 0123456789012345678901234567890123456789
	
Related to this (should maybe go into a MiNT FAQ), in general
if you can't remove/rename/access files because their names
are too long or include special characters (control characters,
slashes, pound sign, ASCII 0 and the like) try:

	# ls >filelist

Edit the filelist with a binary editor (vi will often do) to
your purpose and then type (suppose you want to delete):

	# rm `cat filelist`

The `backticks` will pass the contents of "filelist" as
arguments to the rm command and this output is /not/ evaluated
or expanded by the shell.  This should let you regain control in almost
every case.

Ciao

Guido
-- 
http://stud.uni-sb.de/~gufl0000
mailto:gufl0000@stud.uni-sb.de