Received: from athserv.otenet.gr (athserv.otenet.gr [195.170.0.1])
	by maskin.oden.se (8.8.7/8.8.7) with ESMTP id SAA28888
	for <dlanor@oden.se>; Sun, 15 Mar 1998 18:07:21 +0100 (MET)
Received: from otenet.gr (athe-l05.otenet.gr [195.167.120.196])
	by athserv.otenet.gr (8.8.8/8.8.8) with SMTP id TAA08766
	for <dlanor@oden.se (Ronald Andersson)>; Sun, 15 Mar 1998 19:10:31 +0200 (EET)
Date: Sun, 15 Mar 1998 19:10:31 +0200 (EET)
Message-Id: <199803151710.TAA08766@athserv.otenet.gr>
To: dlanor@oden.se (Ronald Andersson)
From: papval@otenet.gr (Vassilis Papathanassiou)
Organization: Private
Subject: Re: Source archives
X-Mailer: NEWSie Version 0.88 (Atari)
X-Sender: POPwatch v2.51 (Atari)
X-UIDL: ea2975e5518962f1e96f0c0171991b70

Hi Ronald

>>Wow, that was FAST !! I received everything in good working order :-) THANKS.
>
>Well, after seeing your obvious disappointment with Peter's response time,
>I felt you needed something speedier to cheer you up...
>
I'm afraid 'Peter's response time' means 'never' for me :-) I hope i'll have
better luck with Ethernet...

>>I'll study them thoroughly, after i finish the XFS (so you'll also have
>>something new to study ! )
>
>That will be great...  I am working on steady improvements of BetaDos and
>its DOS filesystems, especially Cluster.Dos.  The latter now has functional
>user defined symbolic links and the next stage will involve adding support
>for long names with free casing.
>
Huh, i needed this also for the XFS (it has Dopendir AND fsfirst etc) so i
needed a way to convert between the two. MagiC gives a path2DD (directory
descriptor) though, so it makes things a little, hmm, easier.

>  That is a 'biggie', since the 'subdrives'
>may (normally will) be a mixture of 'old_fashioned TOS' and 'longname' types,
>so that longname support and case forcing will have to be simulated by the
>Cluster.Dos driver for some of them.
>
That was a great deal of work for the XFS also (and the main reason for the
delay so far) but now i think i'm close. I've made lots of path tricks again
but i hope this time its better than BNET's original.

>If you've missed that point, let me point out that Cluster.Dos then does all
>of the things for local drives that a future BNet.Dos will need to do for the
>remote drives...  Thus all it will take to make the latter work is to build
>the linkage you have from your BNet.XFS to the BNet.APP into a copy of the
>Cluster.Dos (replacing gemdos calls for local access) and we have a BNet.Dos !
>
I've changed this again ! (the linkage that is) Now BNET.APP installs a
cookie (like STinG's tpl ) so the XFS finds it (when tou try to open the
'bnet' drive for the first time) and then uses the BNET.APP functions.
This (IMO) has two advantages: 1st the XFS stays 'clean' (so for example
Peter can use it for the NFS (in it's XFS or DOS form)) and 2nd (and most
important for now) i can use a debugger to see what the XFS is doing (it's
unfortunately almost impossible to debug a running XFS and i'd love it if
you could prove me wrong !)

>It may turn out to be a bit more complex in reality (it usually does...),
>
Sure, it is most of the time...

>but I am confident that we will get it to work fairly quickly anyway.
>
Me too, we'll do it one way or another.

I hope this week BNET_XFS will be ready for first betatesting. Well, i'm
going back to work with it.

Regards     Vassilis

