er1m+@andrew.cmu.edu (Ethan J. Rasiel) (04/18/91)
I'm sorry if this question is too simple, but it has been puzzling me for some time. 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! Ethan
valley@gsbsun.uchicago.edu (Doug Dougherty) (04/18/91)
er1m+@andrew.cmu.edu (Ethan J. Rasiel) writes: >I'm sorry if this question is too simple, but it has been puzzling me >for some time. >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! Actually, what is happening is that DOS *is* allocating the clusters and yes, your free space should be decreasing (in successive DIR's) even though the filesize remains zero until the very end. This is because DOS does allocate the clusters as needed, but doesn't update the size entry in the directory until it closes the file. -- (Another fine mess brought to you by valley@gsbsun.uchicago.edu)
ralf+@cs.cmu.edu (Ralf Brown) (04/18/91)
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
smsmith@hpuxa.acs.ohio-state.edu (Stephen M. Smith) (04/19/91)
ralf+@cs.cmu.edu (Ralf Brown) writes: > >I use >the tiny 34-byte program created by the following DEBUG script: >[deletions] You are either the most humble person in the world, or you are not the Ralf Brown I'm thinking of!!! :) If the original poster would like to see just how much space the file that is being downloaded is taking, they should get the program that was written by Ralf Brown called File View. It can be obtained from wuarchive.wustl.edu in /mirrors/msdos/ desqview. The program is GREAT! Within Desqview if you start it up it opens a window and shows all the open files on your drive, and gives you some important info on each one; included in that info is the size of the file which is always current-- that is, you can watch the size of your file grow in bytes as it is being downloaded. File View runs in foreground, background, and you can scale its window. In addition, it only takes 16k RAM--and that INCLUDES any needed Desqview overhead. Steve Smith smsmith@hpuxa.ircc.ohio-state.edu
ralf+@cs.cmu.edu (Ralf Brown) (04/19/91)
In article <1991Apr18.201621.21353@magnus.acs.ohio-state.edu> smsmith@hpuxa.acs.ohio-state.edu (Stephen M. Smith) writes: }If the original poster would like to see just how much space }the file that is being downloaded is taking, they should get }the program that was written by Ralf Brown called File View. }It can be obtained from wuarchive.wustl.edu in /mirrors/msdos/ }desqview. The program is GREAT! Within Desqview if you start }it up it opens a window and shows all the open files on your 'Twasn't me. FILES004 was written by Bill Bond using a few DV API glue functions I wrote a long time ago, and the guts of a program from _Undocumented_DOS_. -- {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
bodoh@cat3.cs.wisc.edu (Daniel Bodoh) (04/19/91)
In article <Mc3JcKS00awJECnGJN@andrew.cmu.edu> er1m+@andrew.cmu.edu (Ethan J. Rasiel) writes: [Stuff deleted] >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. [More stuff deleted] >I assume this happens >because deskview doesn't allocate the clusters for the file until it is >finished writing the file. > >Ethan I don't think this has anything to do with DESQview, but how DOS opens files. The info you see in a DIR is not updated until the DOS call that closes the file is called. If you get out of DESQview and use a text editor to edit a file, then shell out and do a directory, you'll see the same thing. In other words, it's nothing to worry about. In fact, you see the same thing in UNIX. Dan Bodoh BTW - Try to format you messages for 80 character screens - it's easier to read for most of us.
mlord@bwdls58.bnr.ca (Mark Lord) (04/21/91)
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
``
endsmsmith@hpuxa.acs.ohio-state.edu (Stephen M. Smith) (04/22/91)
In article <6521@bwdls58.bnr.ca> mlord@bwdls58.bnr.ca (Mark Lord) writes: > >The other window can not allocate 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! Here's a little experiment for you people: Start downloading a file in one window, then switch to another window which has a DOS prompt (BIG DOS is a good choice); then enter CHKDSK *without* the /f parameter and you will get the infamous error message which ends with "Convert lost chains to files? (Y/N)". If you use the /f parameter, those clusters which are being written to and reserved for your downloaded file will be gathered into the usual FILES001.CHK file. No harm done, except your file which is downloading is now screwed up royally. Kids, don't try this at home. SS
jpn@genrad.com (John P. Nelson) (04/26/91)
>The info you see in a DIR is not updated until the DOS call that >closes the file is called. True. >In other words, it's nothing to worry about. In fact, you see the same thing >in UNIX. Uh, no. This is NOT true. The filesize is updated immediately under UNIX. The main reason MSDOS doesn't do this is because it doesn't cache any disk writes, and updating the directory every time the file size changed would be prohibatively expensive. Of course, UNIX caches writes to the disk, so it can update things properly without a performance penalty. john nelson uucp: {decvax,mit-eddie}!genrad!jpn domain: jpn@genrad.com