X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-workers-bounces using -f
Message-ID: <250B3114DA16D511B82C00E0094005F8055AC808@MSGWAW11>
From: =?iso-8859-2?Q?Wojciech_Ga=B3=B1zka?= <wojciech DOT galazka AT polkomtel DOT com DOT pl>
To: "'djgpp-workers AT delorie DOT com'" <djgpp-workers AT delorie DOT com>
Subject: RE: lfn from scratch...
Date: Sat, 29 Dec 2001 16:27:43 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-2"
Reply-To: djgpp-workers AT delorie DOT com


> From: Eli Zaretskii [mailto:eliz AT is DOT elta DOT co DOT il]

> > From: <wojciech DOT galazka AT polkomtel DOT com DOT pl>
> > 

> > How about adding yet again possible value
> > set lfn=a 	always use LFN API, even if the filesystem 
> doesn't support 
> > it, the LFN API callee has to handle possible faults on its own
> 
> In what situations would this option be useful?  If the callee is
> expected to be able to cope with the LFN API calls, then why can't it
> just support function 71A0h and return the LFN supported flag when we
> call it?
> 

Let's forget it, it wasn't a good idea. Here's something new

In order to provide the ability for a program (rather than by libc) 
to decide how and when use LFN API, here are my suggestions

CHANGE 
in include/fcntl.h
        #define USE_LFN	_use_lfn(0) /* assume it's the same on ALL drives */
to
	char (*_use_lfn_handler)(const char * _path);
	#define USE_LFN	((*_use_lfn_handler)(NULL)) /* assume it's the same
on ALL drives */

ADD
near the top of src/libc/dos/_use_lfn.c
static _use_lfn_handler = _use_lfn; /* default handler */

Now an application can define its own '_use_lfn' function, for example

char my_use_lfn(const char *_path)
{
	if (some_condition_succeed(_path))
		return 1;
	else 
		returm 0;
}

int main()
{
	...
	 _use_lfn_handler = my_use_lfn;
	...

}

Perhaps this would be useful in cases when the default drive 
does not support LFN API while other drivers do (and for some reasons one is
not willing to change from the non lfn-aware drive to the lfn-ware).

Scenarios:
1. Operating system DOS + LAN Manager
  A diskless workstation with a floppy drive and readonly network shares 
  on a volatile network. If one switches to a network share and the 
  share gets disconnected later then this may cause a problem.  

2. Operating system DOS + device driver for ext2fs partition
  By using this suggestion to limit LFN API only to the ex2fs 
  partition it is not necessary to support LFN API for FAT access (which
  is not trivial - one needs an intelligent filesystem cache to get it
  working fast enough)