|
code
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
File Copy Without Win BufferingCopy a file without using Windows buffers - i.e. direct write to destination. I think it goes like this - Get the sector size of the source and destination. Read sectors to make up a destination sector size. Write a destination sector. Loop until done. Fill the "empty" contents of the last sector with Nulls Close the file. A code snippet would be really helpfull. I cannot figure out the API calls and parameters that are necessary. I can do all of this with regular File System Object etc but canot figure out how to do this without Windows buffering getting in the way. I want to know that the fle got to the destination device so when I read it back I am getting it from the device not from Windows buffers as I am now. I just turned 63 and am so happy to be writing programs - keeps my mind greased. "Lorin" <Lo***@discussions.microsoft.com> wrote Windows buffers?> Need help with a snippet to: > Copy a file without using Windows buffers - i.e. direct write to destination. > I cannot figure out the API calls and parameters that are necessary. How do you tell if you are reading from a buffer?> I can do all of this with regular File System Object etc but canot figure > out how to do this without Windows buffering getting in the way. > I want to know that the fle got to the destination device so when I read it > back I am getting it from the device not from Windows buffers as I am now. I would suggest VB's own Get and Put commands would be the more appropreate solution. You can Get and Put an entire array of data, which if the file is small enough to fit in memory, would be simple to do. Then again, VB has its own FileCopy command that should work for most local copying situations. What special need do you have that requires more than those? LFS "Larry Serflaten" <serfla***@usinternet.com> wrote in Disk caching.news:OcfnBdEJGHA.1424@TK2MSFTNGP12.phx.gbl: > > "Lorin" <Lo***@discussions.microsoft.com> wrote >> Need help with a snippet to: >> Copy a file without using Windows buffers - i.e. direct write to >> destination. > > Windows buffers? > If it's a floppy it is very easy to tell.>> I cannot figure out the API calls and parameters that are necessary. >> I can do all of this with regular File System Object etc but canot >> figure out how to do this without Windows buffering getting in the >> way. > >> I want to know that the fle got to the destination device so when I >> read it back I am getting it from the device not from Windows buffers >> as I am now. > > How do you tell if you are reading from a buffer? > Put in a floppy, open Windows Explorer to the floppy drive. Doulble click to open a file on the floppy. This will take a few seconds. Close the file. Double click to open the file again. This time it opens in 1/2 second or less. Reading from cache. I would think that the OP is talking about copying to/from a floppy. I can't remember the last time I used a floppy disk. "DanS" <t.h.i.s.n.t.h.a.t@a.d.e.l.p.h.i.a..n.e.t> wrote Still that is a guess, there is no other indication where that data actually> >> I want to know that the fle got to the destination device so when I > >> read it back I am getting it from the device not from Windows buffers > >> as I am now. > > > > How do you tell if you are reading from a buffer? > > > If it's a floppy it is very easy to tell. > > Put in a floppy, open Windows Explorer to the floppy drive. Doulble click > to open a file on the floppy. This will take a few seconds. Close the file. > Double click to open the file again. This time it opens in 1/2 second or > less. Reading from cache. came from. I could likewise say that access time is governed by the speed of the drive arm and its ability to be quickly positioned over the data. The first read requires the arm to hit the disk's FAT and then move to the file, while the second read is quicker because the arm is still directly over the file data. When you get that second copy, doesn't the floppy's busy light still come on? Try a larger file if you want to hear the arm move while the second read is happening.... My point is that you can't really tell where that data came from under most circumstances, so I wonder why it is important to know? LFS
Show quote
Hide quote
"Larry Serflaten" <serfla***@usinternet.com> wrote in OK, a 726K file. First copy to HD, 20 seconds. Second copy the drive LED news:e9onknHJGHA.2036@TK2MSFTNGP14.phx.gbl: > > "DanS" <t.h.i.s.n.t.h.a.t@a.d.e.l.p.h.i.a..n.e.t> wrote >> >> I want to know that the fle got to the destination device so when >> >> I read it back I am getting it from the device not from Windows >> >> buffers as I am now. >> > >> > How do you tell if you are reading from a buffer? >> > >> If it's a floppy it is very easy to tell. >> >> Put in a floppy, open Windows Explorer to the floppy drive. Doulble >> click to open a file on the floppy. This will take a few seconds. >> Close the file. Double click to open the file again. This time it >> opens in 1/2 second or less. Reading from cache. > > Still that is a guess, there is no other indication where that data > actually came from. I could likewise say that access time is governed > by the speed of the drive arm and its ability to be quickly positioned > over the data. The first read requires the arm to hit the disk's FAT > and then move to the file, while the second read is quicker because > the arm is still directly over the file data. When you get that > second copy, doesn't the floppy's busy light still come on? Try a > larger file if you want to hear the arm move while the second read is > happening.... is on for 2-3 seconds, but the copy progress bar never comes up. Third copy 2-3 seconds. If you pop the floppy out the back in the first copy then again takes 20 seconds. To me, it seems as though Windows is looing at the file to see if it's changed, and if not, just using the cache. DanS "DanS" <t.h.i.s.n.t.h.a.t@a.d.e.l.p.h.i.a..n.e.t> wrote Either that, or the File Allocation Table takes a REALLY long time to load!> OK, a 726K file. First copy to HD, 20 seconds. Second copy the drive LED > is on for 2-3 seconds, but the copy progress bar never comes up. Third > copy 2-3 seconds. If you pop the floppy out the back in the first copy > then again takes 20 seconds. > > To me, it seems as though Windows is looing at the file to see if it's > changed, and if not, just using the cache. <g> LFS
Show quote
Hide quote
"Larry Serflaten" <serfla***@usinternet.com> wrote in I would hope not, there's only 2 files on the disk !!!!news:usdhTFMJGHA.1192@TK2MSFTNGP11.phx.gbl: > > "DanS" <t.h.i.s.n.t.h.a.t@a.d.e.l.p.h.i.a..n.e.t> wrote > >> OK, a 726K file. First copy to HD, 20 seconds. Second copy the drive >> LED is on for 2-3 seconds, but the copy progress bar never comes up. >> Third copy 2-3 seconds. If you pop the floppy out the back in the >> first copy then again takes 20 seconds. >> >> To me, it seems as though Windows is looing at the file to see if >> it's changed, and if not, just using the cache. > > Either that, or the File Allocation Table takes a REALLY long time to > load! >
Show quote
Hide quote
"Lorin" <Lo***@discussions.microsoft.com> wrote in message If you are trying to do what I think you are trying to do - then the answernews:9BC8E2AA-E4EE-4624-992E-23B234BDD72A@microsoft.com... > Need help with a snippet to: > Copy a file without using Windows buffers - i.e. direct write to destination. > I think it goes like this - > Get the sector size of the source and destination. > Read sectors to make up a destination sector size. > Write a destination sector. > Loop until done. > Fill the "empty" contents of the last sector with Nulls > Close the file. > > A code snippet would be really helpfull. > > I cannot figure out the API calls and parameters that are necessary. > I can do all of this with regular File System Object etc but canot figure > out how to do this without Windows buffering getting in the way. > I want to know that the fle got to the destination device so when I read it > back I am getting it from the device not from Windows buffers as I am now. > I just turned 63 and am so happy to be writing programs - keeps my mind > greased. > is you can't. You can read/write to the disk without 'buffering' using the WinAPI but the last time that really worked was with Win98. All most all the "raw" disk access (available to VB), in Win2k/XP and higher, is remapped to some intermediate File I/O and is managed with OS components in their own time slots. You can achieve the illusion of writing directly to 'low-level' devices - but it won't actually happen. You need to go to C/C++, the DDK, and VBXs. Perhaps, if you explained exactly what you are trying to do and how "Windows buffering" is "getting in the way" someone could provide a workaround or better direction. -ralph OK
You all seem not to have an understanding of how Windows works. Using get or put is the same as copyfile etc. It writes to a buffer that Windows then at its own leisure writes to the disk, for example. When you read it back, Windows reads from the buffer not the disk, therefore you really never know if it is on the disk. Then what happens if you write to the file again? Does it write the first buffer if I had not already or does it skip that an write only the new stuff. Does a binary write (sector length or not) actaull write to the disk? You have to, for example, remove and reinstall a pen drive for the buffer to be cleared unless you know (and I do not know) how to purge the Windows buffers or write directly to the disk. There APIs that claim, with the proper parameter, to do direct writes i.e. no buffering. But that requires writin sector size buffer at a time. APIs can do that. So I am looking for someone who understands the OS a little more they most of us seem to. We all need more traiing - especially me! Show quoteHide quote "Ralph" wrote: > > "Lorin" <Lo***@discussions.microsoft.com> wrote in message > news:9BC8E2AA-E4EE-4624-992E-23B234BDD72A@microsoft.com... > > Need help with a snippet to: > > Copy a file without using Windows buffers - i.e. direct write to > destination. > > I think it goes like this - > > Get the sector size of the source and destination. > > Read sectors to make up a destination sector size. > > Write a destination sector. > > Loop until done. > > Fill the "empty" contents of the last sector with Nulls > > Close the file. > > > > A code snippet would be really helpfull. > > > > I cannot figure out the API calls and parameters that are necessary. > > I can do all of this with regular File System Object etc but canot figure > > out how to do this without Windows buffering getting in the way. > > I want to know that the fle got to the destination device so when I read > it > > back I am getting it from the device not from Windows buffers as I am now. > > I just turned 63 and am so happy to be writing programs - keeps my mind > > greased. > > > > If you are trying to do what I think you are trying to do - then the answer > is you can't. > > You can read/write to the disk without 'buffering' using the WinAPI but the > last time that really worked was with Win98. All most all the "raw" disk > access (available to VB), in Win2k/XP and higher, is remapped to some > intermediate File I/O and is managed with OS components in their own time > slots. You can achieve the illusion of writing directly to 'low-level' > devices - but it won't actually happen. You need to go to C/C++, the DDK, > and VBXs. > > Perhaps, if you explained exactly what you are trying to do and how "Windows > buffering" is "getting in the way" someone could provide a workaround or > better direction. > > -ralph > > > What you are looking for is "flush" as in flushing the buffer which forces
it to write to the file. Galen Show quoteHide quote "Lorin" <Lo***@discussions.microsoft.com> wrote in message news:C61861DD-DE5A-4090-A122-303A7AA46E2C@microsoft.com... > OK > You all seem not to have an understanding of how Windows works. > Using get or put is the same as copyfile etc. It writes to a buffer that > Windows then at its own leisure writes to the disk, for example. > When you read it back, Windows reads from the buffer not the disk, therefore > you really never know if it is on the disk. Then what happens if you write > to the file again? Does it write the first buffer if I had not already or > does it skip that an write only the new stuff. Does a binary write (sector > length or not) actaull write to the disk? > You have to, for example, remove and reinstall a pen drive for the buffer to > be cleared unless you know (and I do not know) how to purge the Windows > buffers or write directly to the disk. There APIs that claim, with the > proper parameter, to do direct writes i.e. no buffering. But that requires > writin sector size buffer at a time. APIs can do that. > So I am looking for someone who understands the OS a little more they most > of us seem to. > We all need more traiing - especially me! > > "Ralph" wrote: > > > > > "Lorin" <Lo***@discussions.microsoft.com> wrote in message > > news:9BC8E2AA-E4EE-4624-992E-23B234BDD72A@microsoft.com... > > > Need help with a snippet to: > > > Copy a file without using Windows buffers - i.e. direct write to > > destination. > > > I think it goes like this - > > > Get the sector size of the source and destination. > > > Read sectors to make up a destination sector size. > > > Write a destination sector. > > > Loop until done. > > > Fill the "empty" contents of the last sector with Nulls > > > Close the file. > > > > > > A code snippet would be really helpfull. > > > > > > I cannot figure out the API calls and parameters that are necessary. > > > I can do all of this with regular File System Object etc but canot figure > > > out how to do this without Windows buffering getting in the way. > > > I want to know that the fle got to the destination device so when I read > > it > > > back I am getting it from the device not from Windows buffers as I am now. > > > I just turned 63 and am so happy to be writing programs - keeps my mind > > > greased. > > > > > > > If you are trying to do what I think you are trying to do - then the answer > > is you can't. > > > > You can read/write to the disk without 'buffering' using the WinAPI but the > > last time that really worked was with Win98. All most all the "raw" disk > > access (available to VB), in Win2k/XP and higher, is remapped to some > > intermediate File I/O and is managed with OS components in their own time > > slots. You can achieve the illusion of writing directly to 'low-level' > > devices - but it won't actually happen. You need to go to C/C++, the DDK, > > and VBXs. > > > > Perhaps, if you explained exactly what you are trying to do and how "Windows > > buffering" is "getting in the way" someone could provide a workaround or > > better direction. > > > > -ralph > > > > > > The Windows CreateFile API has a flag that requests, but doesn't enforce,
that file writes not be buffered. Under windows, there is no way to do this unless your device implements the removable device APIs. In this case, the removable device APIs actually enforce the buffer writes. Accessing these APIs from VB is possible, but I would recommend you use C/C++ instead for this type of work as the APIs are directly mapped into the compiler. I do agree that we need to know what you are actually trying to accomplish so that we can point you in the correct direction. Mike Ober. Show quoteHide quote "Galen Somerville" <ga***@surewest.net> wrote in message news:eBzNCRHJGHA.344@TK2MSFTNGP11.phx.gbl... > What you are looking for is "flush" as in flushing the buffer which forces > it to write to the file. > > Galen > > "Lorin" <Lo***@discussions.microsoft.com> wrote in message > news:C61861DD-DE5A-4090-A122-303A7AA46E2C@microsoft.com... > > OK > > You all seem not to have an understanding of how Windows works. > > Using get or put is the same as copyfile etc. It writes to a buffer that > > Windows then at its own leisure writes to the disk, for example. > > When you read it back, Windows reads from the buffer not the disk, > therefore > > you really never know if it is on the disk. Then what happens if you > write > > to the file again? Does it write the first buffer if I had not already or > > does it skip that an write only the new stuff. Does a binary write > (sector > > length or not) actaull write to the disk? > > You have to, for example, remove and reinstall a pen drive for the buffer > to > > be cleared unless you know (and I do not know) how to purge the Windows > > buffers or write directly to the disk. There APIs that claim, with the > > proper parameter, to do direct writes i.e. no buffering. But that > requires > > writin sector size buffer at a time. APIs can do that. > > So I am looking for someone who understands the OS a little more they most > > of us seem to. > > We all need more traiing - especially me! > > > > "Ralph" wrote: > > > > > > > > "Lorin" <Lo***@discussions.microsoft.com> wrote in message > > > news:9BC8E2AA-E4EE-4624-992E-23B234BDD72A@microsoft.com... > > > > Need help with a snippet to: > > > > Copy a file without using Windows buffers - i.e. direct write to > > > destination. > > > > I think it goes like this - > > > > Get the sector size of the source and destination. > > > > Read sectors to make up a destination sector size. > > > > Write a destination sector. > > > > Loop until done. > > > > Fill the "empty" contents of the last sector with Nulls > > > > Close the file. > > > > > > > > A code snippet would be really helpfull. > > > > > > > > I cannot figure out the API calls and parameters that are necessary. > > > > I can do all of this with regular File System Object etc but canot > figure > > > > out how to do this without Windows buffering getting in the way. > > > > I want to know that the fle got to the destination device so when I > read > > > it > > > > back I am getting it from the device not from Windows buffers as I am > now. > > > > I just turned 63 and am so happy to be writing programs - keeps my > mind > > > > greased. > > > > > > > > > > If you are trying to do what I think you are trying to do - then the > answer > > > is you can't. > > > > > > You can read/write to the disk without 'buffering' using the WinAPI but > the > > > last time that really worked was with Win98. All most all the "raw" disk > > > access (available to VB), in Win2k/XP and higher, is remapped to some > > > intermediate File I/O and is managed with OS components in their own > time > > > slots. You can achieve the illusion of writing directly to 'low-level' > > > devices - but it won't actually happen. You need to go to C/C++, the > DDK, > > > and VBXs. > > > > > > Perhaps, if you explained exactly what you are trying to do and how > "Windows > > > buffering" is "getting in the way" someone could provide a workaround or > > > better direction. > > > > > > -ralph > > > > > > > > > > > > "Lorin" <Lo***@discussions.microsoft.com> wrote Is there some reason you have to know? Unless you plan on pulling the plug> OK > You all seem not to have an understanding of how Windows works. > Using get or put is the same as copyfile etc. It writes to a buffer that > Windows then at its own leisure writes to the disk, for example. > When you read it back, Windows reads from the buffer not the disk, therefore > you really never know if it is on the disk. on your computer, Windows file management should be transparent. > Then what happens if you write Again. is there some situation where you have to know what it does?> to the file again? Does it write the first buffer if I had not already or > does it skip that an write only the new stuff. As long as the second write is the one that ends up in the file, why is it important how it got there? > You have to, for example, remove and reinstall a pen drive for the buffer to Check out the Reset command in VB help.> be cleared unless you know (and I do not know) how to purge the Windows > buffers or write directly to the disk. HTH LFS "Larry Serflaten" <serfla***@usinternet.com> wrote in message It's probably more like.... pulling the plug, as in, removing the memory news:OgMoFbHJGHA.140@TK2MSFTNGP12.phx.gbl... > > Is there some reason you have to know? Unless you plan on pulling the > plug > on your computer, Windows file management should be transparent. > stick. I've experienced data loss more than once after yanking the stick too soon (hmmm... that may need to be sensored <g>). Now, I use that "Safely remove hardware" tray icon. -- Ken Halter - MS-MVP-VB - Please keep all discussions in the groups.. DLL Hell problems? Try ComGuard - http://www.vbsight.com/ComGuard.htm Freeware 4 color Gradient Frame? http://www.vbsight.com/GradFrameCTL.htm : stick. I've experienced data loss more than once after yanking the stick Well, some loss at least. <g>too : soon (hmmm... that may need to be censored <g>). -- Randy Birch MS MVP Visual Basic http://vbnet.mvps.org/ Please reply to the newsgroups so all can participate.
Show quote
Hide quote
"=?Utf-8?B?TG9yaW4=?=" <Lo***@discussions.microsoft.com> wrote in Actually, Windows only waits to write to the disk if the 'write behind news:C61861DD-DE5A-4090-A122-303A7AA46E2C@microsoft.com: > OK > You all seem not to have an understanding of how Windows works. > Using get or put is the same as copyfile etc. It writes to a buffer > that Windows then at its own leisure writes to the disk, for example. > When you read it back, Windows reads from the buffer not the disk, > therefore you really never know if it is on the disk. Then what > happens if you write to the file again? Does it write the first > buffer if I had not already or does it skip that an write only the new > stuff. Does a binary write (sector length or not) actaull write to > the disk? You have to, for example, remove and reinstall a pen drive > for the buffer to be cleared unless you know (and I do not know) how > to purge the Windows buffers or write directly to the disk. There > APIs that claim, with the proper parameter, to do direct writes i.e. > no buffering. But that requires writin sector size buffer at a time. > APIs can do that. So I am looking for someone who understands the OS a > little more they most of us seem to. > We all need more traiing - especially me! > cache' is enabled, from what I understand. It will read from cache if the file has not changed, or if subsequent disk access pushes the other info out of the buffers. Again, is this for a floppy ? That is the only reason I can see to care about where the data is coming from. If you copy a file to a floppy and there is a write error that is not reported, subsequent reads to the file will fail. I have had this happen. Wrote to a floppy, copy back to be sure it copied, the go to another PC and the file has a read error. DanS FlushFileBuffers API will flush the buffers of the specified file and causes
all buffered data to be written to the file. Unfortunately, this only applies to files opened and written with CreateFile/WriteFile etc. For VB's intrinsic file access methods (which does not include the file system object), use the Reset statement ... "Reset closes all active files opened by the Open statement and writes the contents of all file buffers to disk." -- Show quoteHide quoteRandy Birch MS MVP Visual Basic http://vbnet.mvps.org/ Please reply to the newsgroups so all can participate. "Lorin" <Lo***@discussions.microsoft.com> wrote in message news:9BC8E2AA-E4EE-4624-992E-23B234BDD72A@microsoft.com... : Need help with a snippet to: : Copy a file without using Windows buffers - i.e. direct write to destination. : I think it goes like this - : Get the sector size of the source and destination. : Read sectors to make up a destination sector size. : Write a destination sector. : Loop until done. : Fill the "empty" contents of the last sector with Nulls : Close the file. : : A code snippet would be really helpfull. : : I cannot figure out the API calls and parameters that are necessary. : I can do all of this with regular File System Object etc but canot figure : out how to do this without Windows buffering getting in the way. : I want to know that the fle got to the destination device so when I read it : back I am getting it from the device not from Windows buffers as I am now. : I just turned 63 and am so happy to be writing programs - keeps my mind : greased. : > FlushFileBuffers API will flush the buffers of the specified file and Okay... how long has that statement been available? I've been using eithercauses > all buffered data to be written to the file. Unfortunately, this only > applies to files opened and written with CreateFile/WriteFile etc. For VB's > intrinsic file access methods (which does not include the file system > object), use the Reset statement ... "Reset closes all active files opened > by the Open statement and writes the contents of all file buffers to disk." BASIC or VB for more than 25 years now and I can't remember ever seeing it before. I see it is used in place of the Close statement... does that mean it MUST be used to close the file in order to flush the buffers? What I mean is... if you Open a file and close it normally (that is, you use the Close statement to close it), will a subsequent Reset statement still flush the buffers? Or is it mandatory that it be used in place of the Close statement in order for it to perform its flush function? Rick It can be used on its own either as a replacement for close or subsequent to
calling the Close statement. But Reset will close all other files that had been opened, not just the file opened in the immediate procedure. So it's best to use it when you're sure nothing else requires a file to be opened. -- Show quoteHide quoteRandy Birch MS MVP Visual Basic http://vbnet.mvps.org/ Please reply to the newsgroups so all can participate. "Rick Rothstein [MVP - Visual Basic]" <rickNOSPAMnews@NOSPAMcomcast.net> wrote in message news:%23$iW8tIJGHA.3944@tk2msftngp13.phx.gbl... :> FlushFileBuffers API will flush the buffers of the specified file and : causes : > all buffered data to be written to the file. Unfortunately, this only : > applies to files opened and written with CreateFile/WriteFile etc. For : VB's : > intrinsic file access methods (which does not include the file system : > object), use the Reset statement ... "Reset closes all active files : opened : > by the Open statement and writes the contents of all file buffers to : disk." : : Okay... how long has that statement been available? I've been using either : BASIC or VB for more than 25 years now and I can't remember ever seeing it : before. : : I see it is used in place of the Close statement... does that mean it MUST : be used to close the file in order to flush the buffers? What I mean is... : if you Open a file and close it normally (that is, you use the Close : statement to close it), will a subsequent Reset statement still flush the : buffers? Or is it mandatory that it be used in place of the Close statement : in order for it to perform its flush function? : : Rick : : Lively discussion.
Reset Does NOT flush the buffers even though the docs say it does. Believe me I have tried it. I know about Flushbuffers but not sure exactly how to use WriteFile / CreateFile to do a copy. Need to know sector size and compute stuff taht I am not too sure about. Do not want to wipe out my disk trying. OK so you want to know what I am trying to do. Wipe a file! Open the file, write garbage to it several times then delete it. I expect to have to open and close the file for each wipe attempt. I want to make sure the data is actually written to the disk surface. So binary put is right for that data should go right back to the same sector (maybe). However, how does one flush the buffer to make sure the data got to the file? If you read it back to verify you are only seeeng the buffer not the disk. Maybe some low level routines are needed. Must be do-able since there are many wipe programs out there that claim towork. Show quoteHide quote "Randy Birch" wrote: > It can be used on its own either as a replacement for close or subsequent to > calling the Close statement. But Reset will close all other files that had > been opened, not just the file opened in the immediate procedure. So it's > best to use it when you're sure nothing else requires a file to be opened. > > -- > > Randy Birch > MS MVP Visual Basic > http://vbnet.mvps.org/ > > Please reply to the newsgroups so all can participate. > > > > > "Rick Rothstein [MVP - Visual Basic]" <rickNOSPAMnews@NOSPAMcomcast.net> > wrote in message news:%23$iW8tIJGHA.3944@tk2msftngp13.phx.gbl... > :> FlushFileBuffers API will flush the buffers of the specified file and > : causes > : > all buffered data to be written to the file. Unfortunately, this only > : > applies to files opened and written with CreateFile/WriteFile etc. For > : VB's > : > intrinsic file access methods (which does not include the file system > : > object), use the Reset statement ... "Reset closes all active files > : opened > : > by the Open statement and writes the contents of all file buffers to > : disk." > : > : Okay... how long has that statement been available? I've been using either > : BASIC or VB for more than 25 years now and I can't remember ever seeing it > : before. > : > : I see it is used in place of the Close statement... does that mean it MUST > : be used to close the file in order to flush the buffers? What I mean is... > : if you Open a file and close it normally (that is, you use the Close > : statement to close it), will a subsequent Reset statement still flush the > : buffers? Or is it mandatory that it be used in place of the Close > statement > : in order for it to perform its flush function? > : > : Rick > : > : > > "Lorin" <Lo***@discussions.microsoft.com> wrote For more related information, here is an earlier discussion on deleting files:> Lively discussion. http://groups.google.com/group/microsoft.public.vb.winapi/browse_frm/thread/26f3d15bc0c8ce0e/f465669bc3c5d26c?tvc=1&q=residual+magnetism++group%3AMicrosoft.public.vb.*&hl=en#f465669bc3c5d26c (be sure to use the entire link in your browser) LFS 
Other interesting topics
Stumped -- trying to update a VBA subroutine for VB.net
Array Nomenclature Problem with NOT How to print a file produced by "Print to File" Ascertain number of fields in a user defined type Help - What is the best approach? Short file names make vb6 exe run only on specified computer?... VBA stealing keys from ActiveX control? Strange 'Replace' problems |
|||||||||||||||||||||||
