Path: utzoo!utgpu!cunews!bnrgate!bwdls58!mlord
From: mlord@bwdls58.bnr.ca (Mark Lord)
Newsgroups: comp.os.msdos.apps
Subject: Re: deskview question
Message-ID: <6521@bwdls58.bnr.ca>
Date: 21 Apr 91 16:40:00 GMT
References: <Mc3JcKS00awJECnGJN@andrew.cmu.edu>
Sender: mlord@bwdls58.bnr.ca
Reply-To: mlord@bwdls58.bnr.ca (Mark Lord)
Organization: Bell-Northern Research, Ottawa, Canada
Lines: 29

In article <Mc3JcKS00awJECnGJN@andrew.cmu.edu> er1m+@andrew.cmu.edu (Ethan J. Rasiel) writes:
<Say I open 2 deskview windows, and start downloading a file in one of the them.
<Then I switch to the other window.  The file that is downloading appears as a 0
<length file regardless of how much has been actually downloaded. If I do a dir,
<I assume that the amount of free space dos reports is therefore wrong,
<since dos isn't accounting for the file that is not fully downloaded yet.  I
<assume this happens
<because deskview doesn't allocate the clusters for the file until it is
<finished writing
<the file.  So, what prevents me from writing to the same area from the other 

Well, it is DOS, not DESQVIEW that is managing the file I/O.  In this case,
DOS creates the new file, and as things are written to it, clusters get 
allocated from the FAT (marked as in-use).  DOS keeps track of the chain of
clusters belonging to the file, but does not update the directory entry for
the new file until the file is closed.

The other window can not be allocated the same clusters since they are marked
as in-use in the FAT as they are taken by the first window.  However, unless
you are running the SHARE.EXE thingie (or maybe even if you do run it :) ),
nothing prevents deleting the new file from the second window while the first
window is still writing to it.  Solution?  Don't do it!
-- 
MLORD@BNR.CA  Ottawa, Ontario *** Personal views only ***
begin 644 NOTSHARE.COM ; Free MS-DOS utility - use instead of SHARE.EXE
MZQ.0@/P/=`J`_!9T!2[_+H``L/_/+HX&+`"T2<TAO@,!OX0`N1(`C,B.P/.DS
<^K@A-<TAB1Z``(P&@@"ZA`"X(27-(?NZE@#-)P#-5
``
end