Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!uwm.edu!bionet!agate!ucbvax!tut.cis.ohio-state.edu!sei.cmu.edu!fs7.ece.cmu.edu!o.gp.cs.cmu.edu!ralf
From: ralf+@cs.cmu.edu (Ralf Brown)
Newsgroups: comp.os.msdos.apps
Subject: Re: deskview question
Message-ID: <1991Apr18.163928.16521@cs.cmu.edu>
Date: 18 Apr 91 16:39:28 GMT
References: <Mc3JcKS00awJECnGJN@andrew.cmu.edu>
Sender: netnews@cs.cmu.edu (USENET News Group Software)
Organization: School of Computer Science, Carnegie Mellon
Lines: 51

In article <Mc3JcKS00awJECnGJN@andrew.cmu.edu> "Ethan J. Rasiel" <er1m+@andrew.cmu.edu> 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 
}window?  I hope this makes sense!

The free space does in fact account for the partially downloaded file.
Clusters are allocated as soon as they are needed, but the directory entry for
a file is not updated until it is closed or a "commit" call is issued.
Under DOS 3.1 and up, you can force all open files to be completely updated
on the disk (including directory entries) with an undocumented call.  I use
the tiny 34-byte program created by the following DEBUG script:

	a100
	mov ax,5d01
	mov dx,010a
	int 21
	int 20

	f 10a l18 0
	rcx
	22
	n sync.com
	w
	q

Store the above in a file called SYNC.SCR (the blank line is important!),
and invoke DEBUG with

	DEBUG <SYNC.SCR

If you run SYNC from another window while downloading, the directory entry
for the file being downloaded will be updated to reflect the portion of the
file already written to disk (it will be a few K less than the amount shown
by your comm program, which will buffer data and write it out when its buffer
is full).


--
{backbone}!cs.cmu.edu!ralf  ARPA: RALF@CS.CMU.EDU   FIDO: Ralf Brown 1:129/3.1
BITnet: RALF%CS.CMU.EDU@CMUCCVMA   AT&Tnet: (412)268-3053 (school)   FAX: ask
DISCLAIMER?  Did  | It isn't what we don't know that gives us trouble, it's
I claim something?| what we know that ain't so.  --Will Rogers