To: caldera-opendos AT caldera DOT com
Cc: opendos AT delorie DOT com
References: <3 DOT 0 DOT 2 DOT 16 DOT 19970806200226 DOT 194780d0 AT acadiacom DOT net>
Message-Id: <ABTXWwpK61@belous.munic.msk.su>
From: "Arkady V.Belousov" <ark AT belous DOT munic DOT msk DOT su>
Date: Thu,  7 Aug 1997 21:39:41 +0400 (MSD)
Organization: Locus
Reply-To: ark AT mos DOT ru
Subject: Re: LFN's...
MIME-Version: 1.0
Lines: 27
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 8bit
Precedence: bulk

X-Comment-To: Jonathan Roberts

Hi!

6-Авг-97 20:02 jonathan AT acadiacom DOT net (Jonathan Roberts) wrote to caldera-opendos AT caldera DOT com:

 > Has anyone else noticed the problems that still exist with the LFN
 > implementation?  I have noticed that if you copy a normal 8.3 file to
 > another DIR, it sometimes gets truncated to a filename with ~1 instead of
 > staying as it should.  Also, the LFN that matches with a SFN gets scrambled
 > sometimes after deleting another file or DIR.  The problem with the LFN/SFN
 > mixmatch is fixed after running DISKOPT.  Anyway, that's all I've found so
 > far.

     This is not a Caldera trouble - this is Miscrosoft infinity wisdom leak
or evil strategy, headed to push out competitors through incompatabilities.

     Best way up to now I found is to use DOSLFNBK utility to backup all
LFNs periodicaly and restore them when required - for example, after
Norton SpeedDisk or after copying directory hierarchy through network.

     Turn attention - native M$'s LFNBAK requires for itself GUI! Despite of
GUI dependance from LFN. Sucks.
--
                Best regards! Sincerely yours, Хемуль Советикус.
       Утомлённый чаем любитель сладкого, в девичестве Бильбо Ленивчатый.