X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-workers-bounces using -f
From: Martin Str|mberg <ams AT ludd DOT luth DOT se>
Message-Id: <200112270205.DAA14770@father.ludd.luth.se>
Subject: Re: lfn from scratch...
In-Reply-To: <3942-Wed26Dec2001220719+0200-eliz@is.elta.co.il> from Eli Zaretskii at "Dec 26, 2001 10:07:19 pm"
To: djgpp-workers AT delorie DOT com
Date: Thu, 27 Dec 2001 03:05:22 +0100 (MET)
X-Mailer: ELM [version 2.4ME+ PL54 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

According to Eli Zaretskii:
> > From: sandmann AT clio DOT rice DOT edu (Charles Sandmann)
> > Date: Wed, 26 Dec 2001 12:32:09 -0600 (CST)
> > 
> > > > What's the best way to tell djgpp programs that *one* drive supports
> > > > LFNs and the others don't?
> > > 
> > > DJGPP doesn't cope well with this situation.
> > 
> > Should we look at fixing it?
> 
> It would be nice, but I'm afraid it will require non-trivial
> changes.  We should probably have two functions instead of _use_lfn:
> one for testing the LFN API support, the other testing whether a
> certain disk can store long file names.  They both should use some
> caching, to be efficient, and library functions should use one or the
> other, depending on what they need.

For caching, I've a similar code for FAT32. If I can find it. Anyway
for the FAT32 caching ability look in the archives of djggp-workers or
ask me if I can find it.

> > I always assumed UNCs were not supported at all.
> 
> That's about right.  As soon as a UNC gets taken apart by library
> functions, like to find the drive letter, we fail.  If the UNC goes
> directly to the system call, it will usually work, at least on
> Windows.
> 
> > Should we fix this?
> 
> It's not clear to me how to fix this.  We should either augment those
> library functions which tinker with file names to know about UNCs, or
> write code to map between a UNC and a drive letter.  The latter is
> safer, but since the mapping can be changed behind our back (the user
> can run "net use" from another DOS box), we cannot cache the mapping,
> and will need to compute the drive letter each time, which will slow
> down file-related system calls (especially since network-related calls
> are slow).

We could say "if you're out on the net, expect a slowdown".

I think UNC would be a welcome addition to DJGPP. But I seem to recall
that you don't have much time.

Anyway it's probably a 2.04 or later issue.


Right,

						MartinS