|
code
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
RESET does what?the buffers. Probably for OPEN only??? Does that include filesystemobject? How aout API open and copy? But what does that help doc really mean? I use OPEN to open a file. I write buffers of that file to a new file on a Pen drive. I close the file and RESET. Now I OPEN the file on the Pen drive and compare the data byte for byte. It all compares, however it did not really read the Pen drive (no activity light on the Pen drive). It was reading some memory buffer. I remove the pen drive then reinsert it. Now when I do the byte for byte compare I see activity. How do I do that programatically (with out remving and reinserting the Pen drive)? RESET does nothing for this. Is there some API to reset a device, be it a Pen drive or the C:\ drive etc that will really flush the buffers? On Sun, 9 Oct 2005 19:05:01 -0700, "Lorin"
<Lo***@discussions.microsoft.com> wrote: >OK, I read the help docs and it says that RESET closes all files and flushes Yes. Essentially it closes and calls the FlushFileBuffers Api function>the buffers. >Probably for OPEN only??? for each file Open'ed. (Note you cannot do this yourself when using VB file methods since VB does not expose the Api file handle(s)) >Does that include filesystemobject? How aout API open and copy? No, and no.>But what does that help doc really mean? I suspect you're worrying about things you don't have to here. It>I use OPEN to open a file. >I write buffers of that file to a new file on a Pen drive. >I close the file and RESET. >Now I OPEN the file on the Pen drive and compare the data byte for byte. >It all compares, however it did not really read the Pen drive (no activity >light on the Pen drive). It was reading some memory buffer. >I remove the pen drive then reinsert it. >Now when I do the byte for byte compare I see activity. means the buffer gets written, but it does not mean the buffer gets destroyed immediately afterward. That sort of thing is the purvey of the OS file system. It manages things at that level so we don't have to (read/write checks, etc). Your own observations actually demonstrate it knows when it can re-read the buffer or needs to read the physical media. Typically if there's some unexpected hardware problem resulting in a bad write it will detect it and tell you (or the user) ...usually in not-so-subtle terms. :-) -Tom MVP - Visual Basic (please post replies to the newsgroup) Perhaps, however when one is trying to reduce the worry of others by doing a
real verify it is incumbent on me to do just that. The destiation could be a floppy, Cd-RW, Pen drive or network drive. "They" want to know it really got there and you know how they are. Does anyone else have input? Please. Thank you Show quoteHide quote "Tom Esh" wrote: > On Sun, 9 Oct 2005 19:05:01 -0700, "Lorin" > <Lo***@discussions.microsoft.com> wrote: > > >OK, I read the help docs and it says that RESET closes all files and flushes > >the buffers. > >Probably for OPEN only??? > Yes. Essentially it closes and calls the FlushFileBuffers Api function > for each file Open'ed. (Note you cannot do this yourself when using VB > file methods since VB does not expose the Api file handle(s)) > > >Does that include filesystemobject? How aout API open and copy? > No, and no. > > >But what does that help doc really mean? > >I use OPEN to open a file. > >I write buffers of that file to a new file on a Pen drive. > >I close the file and RESET. > >Now I OPEN the file on the Pen drive and compare the data byte for byte. > >It all compares, however it did not really read the Pen drive (no activity > >light on the Pen drive). It was reading some memory buffer. > >I remove the pen drive then reinsert it. > >Now when I do the byte for byte compare I see activity. > > I suspect you're worrying about things you don't have to here. It > means the buffer gets written, but it does not mean the buffer gets > destroyed immediately afterward. That sort of thing is the purvey of > the OS file system. It manages things at that level so we don't have > to (read/write checks, etc). Your own observations actually > demonstrate it knows when it can re-read the buffer or needs to read > the physical media. Typically if there's some unexpected hardware > problem resulting in a bad write it will detect it and tell you (or > the user) ...usually in not-so-subtle terms. :-) > > > -Tom > MVP - Visual Basic > (please post replies to the newsgroup) > On Sun, 9 Oct 2005 23:39:03 -0700, "Lorin"
<Lo***@discussions.microsoft.com> wrote: >Perhaps, however when one is trying to reduce the worry of others by doing a Then you'll have to resort to Api methods. More work for sure, but>real verify it is incumbent on me to do just that. The destiation could be a >floppy, Cd-RW, Pen drive or network drive. "They" want to know it really got >there and you know how they are. with for example with CreateFile (also opens existing files), you can specify the FILE_FLAG_NO_BUFFERING and FILE_FLAG_WRITE_THROUGH flags. -Tom MVP - Visual Basic (please post replies to the newsgroup) The last question still remains.
Is there a way to cause a drive to close, flushing the memory buffer that does not get flushed by RESET, then reopen it? Is the only way to create a file using API calls and proper flags? Any examples in the MSDN Lib? If a file already exists, then delete, create with flags and copy. I need to copy buffers worth so that the API does not keep my App from responding to user input, refreshes etc. I usually do this with VB OPEN and PUT relatively small buffers worth of data out at a time. Show quoteHide quote "Tom Esh" wrote: > On Sun, 9 Oct 2005 23:39:03 -0700, "Lorin" > <Lo***@discussions.microsoft.com> wrote: > > >Perhaps, however when one is trying to reduce the worry of others by doing a > >real verify it is incumbent on me to do just that. The destiation could be a > >floppy, Cd-RW, Pen drive or network drive. "They" want to know it really got > >there and you know how they are. > > Then you'll have to resort to Api methods. More work for sure, but > with for example with CreateFile (also opens existing files), you can > specify the FILE_FLAG_NO_BUFFERING and FILE_FLAG_WRITE_THROUGH flags. > > > -Tom > MVP - Visual Basic > (please post replies to the newsgroup) > On Tue, 11 Oct 2005 20:16:01 -0700, "Lorin"
<Lo***@discussions.microsoft.com> wrote: > Not sure. Maybe - if you re-open it with CreateFile and the>The last question still remains. >Is there a way to cause a drive to close, flushing the memory buffer that >does not get flushed by RESET, then reopen it? FILE_FLAG_NO_BUFFERING and FILE_FLAG_WRITE_THROUGH flags. However for sure I'd avoid mixing VB and Api file methods. >Is the only way to create a file using API calls and proper flags? Well, strictly speaking you don't need the Api to create it, just to>Any examples in the MSDN Lib? open it and write to it, but yes, the Api is the only way to avoid buffering. Should be plenty of examples. Some here: http://vbnet.mvps.org/ ....and a google search on VB+Api+CreateFile should up more. >If a file already exists, then delete, create with flags and copy. The Api actually offers extensive capabilities with regard to>I need to copy buffers worth so that the API does not keep my App from >responding to user input, refreshes etc. >I usually do this with VB OPEN and PUT relatively small buffers worth of >data out at a time. asynchronous and/or monitored transfers via callbacks. Fairly complicated stuff though. For sure I'd get things working in block mode (like you're doing now) before going there :-) -Tom MVP - Visual Basic (please post replies to the newsgroup) On Tue, 11 Oct 2005 20:16:01 -0700, "=?Utf-8?B?TG9yaW4=?="
<Lo***@discussions.microsoft.com> wrote: > I've been following this thread with some interest.>The last question still remains. >Is there a way to cause a drive to close, flushing the memory buffer that >does not get flushed by RESET, then reopen it? You appear to want to: a) Ensure data is fully written to the device b) Read back the real data (not a buffer) to validate Probably your best bet is to bite the bullet and go straight for the APIs - they are pretty horrible at first sight, but can be boxed up. You need to dig out the Win32 Programmer's Reference Help File - also examples from the downloadable API Guide will be helpful http://www.mentalis.org/agnet/ Here is a taste of what you are in for: FILE_FLAG_NO_BUFFERING Instructs the operating system to open the file with no intermediate buffering or caching. This can provide performance gains in some situations. An application must meet certain requirements when working with files opened with FILE_FLAG_NO_BUFFERING:· File access must begin at byte offsets within the file that are integer multiples of the volume's sector size. · File access must be for numbers of bytes that are integer multiples of the volume's sector size. For example, if the sector size is 512 bytes, an application can request reads and writes of 512, 1024, or 2048 bytes, but not of 335, 981, or 7171 bytes. · Buffer addresses for read and write operations must be aligned on addresses in memory that are integer multiples of the volume's sector size. I've been working with RAM and other memory cards for 15 years now, the current ones are USB Memory Sticks. My current approach is to build the entire file in RAM then slap it down in one go. The files are not that large so it works. The reason for this is that the devices use EEPROM which is written in 16kb chunks (not sure about the 16kb nowadays) so small writes either have to be collected or one gets a heck of a lot of re-writing. Before you launch off on anything drastic, it might be an idea to check whether reading back the data for validation really reads from the buffer. Also, it is very likely that if you have one small file that you Open/Write/Close using the APIs will actually trigger a full buffer refresh - my hunch is that Windows buffers contiguous clusters or sectors - and on a relatively small device you might be forcing a full refresh. I also suspect that Windows is well aware that the device is removeable, regardless of what it says, you may be able to rely on the built in Verify. Perhaps a bad assumption, but the pen drive light does not wink when reading
back. not reading the pen drive. If I pull it then plug it and read back right after this first attempt the light winks on the pen drive. reading the pen drive. I and writing hunderds of megabytes and want my app to be awake during this so i break the file into chunks so my app can gasp a little. Show quoteHide quote "J French" wrote: > On Tue, 11 Oct 2005 20:16:01 -0700, "=?Utf-8?B?TG9yaW4=?=" > <Lo***@discussions.microsoft.com> wrote: > > > > >The last question still remains. > >Is there a way to cause a drive to close, flushing the memory buffer that > >does not get flushed by RESET, then reopen it? > > I've been following this thread with some interest. > > You appear to want to: > > a) Ensure data is fully written to the device > b) Read back the real data (not a buffer) to validate > > Probably your best bet is to bite the bullet and go straight for the > APIs - they are pretty horrible at first sight, but can be boxed up. > > You need to dig out the Win32 Programmer's Reference Help File > - also examples from the downloadable API Guide will be helpful > http://www.mentalis.org/agnet/ > > Here is a taste of what you are in for: > > FILE_FLAG_NO_BUFFERING > Instructs the operating system to open the file with no intermediate > buffering or caching. This can provide performance gains in some > situations. An application must meet certain requirements when working > with files opened with FILE_FLAG_NO_BUFFERING:· File access must begin > at byte offsets within the file that are integer multiples of the > volume's sector size. · File access must be for numbers of bytes that > are integer multiples of the volume's sector size. For example, if the > sector size is 512 bytes, an application can request reads and writes > of 512, 1024, or 2048 bytes, but not of 335, 981, or 7171 bytes. · > Buffer addresses for read and write operations must be aligned on > addresses in memory that are integer multiples of the volume's sector > size. > > I've been working with RAM and other memory cards for 15 years now, > the current ones are USB Memory Sticks. > > My current approach is to build the entire file in RAM then slap it > down in one go. The files are not that large so it works. > > The reason for this is that the devices use EEPROM which is written in > 16kb chunks (not sure about the 16kb nowadays) so small writes either > have to be collected or one gets a heck of a lot of re-writing. > > Before you launch off on anything drastic, it might be an idea to > check whether reading back the data for validation really reads from > the buffer. > > Also, it is very likely that if you have one small file that you > Open/Write/Close using the APIs will actually trigger a full buffer > refresh - my hunch is that Windows buffers contiguous clusters or > sectors - and on a relatively small device you might be forcing a full > refresh. > > I also suspect that Windows is well aware that the device is > removeable, regardless of what it says, you may be able to rely on the > built in Verify. > > > On Wed, 12 Oct 2005 22:06:02 -0700, "=?Utf-8?B?TG9yaW4=?="
<Lo***@discussions.microsoft.com> wrote: > Fair enough, I was not sure of your application>Perhaps a bad assumption, but the pen drive light does not wink when reading >back. not reading the pen drive. > >If I pull it then plug it and read back right after this first attempt the >light winks on the pen drive. reading the pen drive. > >I and writing hunderds of megabytes and want my app to be awake during this >so i break the file into chunks so my app can gasp a little. I wonder if it is possible to 'dismount' the drive from software - I am sure I saw something in another NG where someone was trying to do that I've just checked, it was a Delphi NG The answer was: Download scapi and win32api from http://www.sf.net/projects/jedi-apilib In scapi there are the examples USbView and SafeRemoval which should tell you all you need to know. I've looked at the code (can't run it - it is a later version of Delphi) and it looks as if it is using IOCTL You may be better off using the APIs for filing - at least they are generic  
Thread options
Other interesting topics
.NOT My Views
Reverse Array order ? Cannot Load Form! Why can't I test class functions from the Immediate window? advanced tooltip bubbles question How should one form call another? Point me in the right direction - Mouse utility... Activex Exe How to handle data types in custom Max/Min function? Insert ActiveX into HTML |
|||||||||||||||||||||||
