Message-Id: <199807310218.DAA02337@sable.ox.ac.uk>
Comments: Authenticated sender is <mert0407 AT sable DOT ox DOT ac DOT uk>
From: George Foot <george DOT foot AT merton DOT oxford DOT ac DOT uk>
To: DJ Delorie <dj AT delorie DOT com>
Date: Fri, 31 Jul 1998 03:16:56 +0000
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: LFN fallbacks?
Reply-to: george DOT foot AT merton DOT oxford DOT ac DOT uk
CC: djgpp-workers AT delorie DOT com
Precedence: bulk

On 30 Jul 98 at 16:54, DJ Delorie wrote:

> Just a thought... If open() fails to find a given file (open for
> reading, at least), should we try switching LFN and trying again?
> I.e. default to the $LFN settings like we do now, but try the other
> way too?

I don't think so, it could have strange results.  Wouldn't there be a
lot of changes to various functions, for consistency?  An application
could use the return value of `open' to determine whether a file was
writable (not a good technique, admittedly), then assume that it can
(for example) delete the file using `unlink'.  So `unlink' would need
to be changed, so that:

    unlink ("my_longly_named_file");

would first try to delete `my_longly_named_file', then if that file
did not exist it would try to delete `my_longl' (or `my_longl.y_n'?).
I don't think that would be acceptable behaviour. This may be a pretty 
weak example, but I think there must be other similar scenarios where 
this sort of problem would occur.

I think ultimately people have to make up their minds whether or not 
they want long filenames, and stick with it.  If they do want long 
filenames then they need to use (for example) an unzip program that 
understands them.

-- 
george DOT foot AT merton DOT oxford DOT ac DOT uk