how overwrite existing file instead of append to it

[porphyry5]

I read a file into memory, make some changes to it, then wish to overwrite the original file with the changed data.  But WriteFile appends the changes to the original.

Do I use SetEndOfFile after setting the current position of the file pointer to the beginning of the file?  If so, what is the file pointer, fsize, fbr or what?

[donkey]

Set the dwCreationDisposition parameter of CreateFile to TRUNCATE_EXISTING.

[porphyry5]

Set the dwCreationDisposition parameter of CreateFile to TRUNCATE_EXISTING.

Many thanks. I passed that by because it sounded as if it would truncate the file before I could read it.

[porphyry5]

Set the dwCreationDisposition parameter of CreateFile to TRUNCATE_EXISTING.

Many thanks. I passed that by because it sounded as if it would truncate the file before I could read it.

Correction; thanks for nothing!  It does truncate the file before I can read it.

[jj2007]

Correction; thanks for nothing!  It does truncate the file before I can read it.

If you open the file for reading and writing, you need to use SetFilePointer with distance 0 and FILE_BEGIN to reset the file pointer after reading.

[donkey]

Set the dwCreationDisposition parameter of CreateFile to TRUNCATE_EXISTING.

Many thanks. I passed that by because it sounded as if it would truncate the file before I could read it.

Correction; thanks for nothing!  It does truncate the file before I can read it.

Open the file for read access, read it into memory, close the handle then re-open it with TRUNCATE_EXISTING and write your new data. I didn't explain this as it seemed kind of obvious and you're welcome for "nothing".

[hutch--]

You can save yourself the messing around with a file you load fully into memory, change its content then write it back to memory by using the following flag.

Code Select Expand


CREATE_ALWAYS Creates a new file. The function overwrites the file if it exists.


Also, don't give lip to our members who have tried to help you out.

[porphyry5]

Correction; thanks for nothing!  It does truncate the file before I can read it.

If you open the file for reading and writing, you need to use SetFilePointer with distance 0 and FILE_BEGIN to reset the file pointer after reading.

Thank you, that seems to be what I was looking for.

[porphyry5]

You can save yourself the messing around with a file you load fully into memory, change its content then write it back to memory by using the following flag.

Code Select Expand


CREATE_ALWAYS Creates a new file. The function overwrites the file if it exists.


Also, don't give lip to our members who have tried to help you out.

Thank you for the info re CREATE_ALWAYS.

And its not a case of my giving lip to Donkey, more a result of unwarranted assumptions.  On my part for assuming it was obvious that I wanted to avoid unnecessarily closing and reopening the file; on Donkey's part for assuming that that was what I wanted to do.

[jj2007]

... unwarranted assumptions.  On my part for assuming it was obvious that I wanted to avoid unnecessarily closing and reopening the file; on Donkey's part for assuming that that was what I wanted to do.

Just add my assumption (for using SetFilePointer with distance 0 and FILE_BEGIN) that your content is not shorter after you modified it ;-)

[hutch--]

hmmmm,

> On my part for assuming it was obvious that I wanted to avoid unnecessarily closing and reopening the file; on Donkey's part for assuming that that was what I wanted to do.

Understand that while many of our members are wizards, they are not yet mind readers and with any unclear questions they have to make assumptions about what your intent may be. Instead of giving lip to a member who had tried to comprehend what you were after and actually assist you, try better specifying your question so they don't have to make assumptions about what you are doing. File IO is in fact no big deal, its fully documented by the vendor and it has ajustments for performing a wide range of tasks. The best way to get NO answer is to be rude to people who are spending their spare time helping others.

[jj2007]

Understand that while many of our members are wizards, they are not yet mind readers

That is my mantra, too, but in Graham's case it was pretty obvious that he was reading the file in and then wrote to it using the same handle, otherwise why should he see content appended? I guess he lost a file when testing TRUNCATE_EXISTING, and that can provoke a sour answer... let's cool down collectively and enjoy the wonderful world of assembly programming, folks :U

[brethren]

instead of being rude to the very people trying to help you why don't you read the documentation for CreateFile, SetFilePointer and WriteFile? It isn't that difficult :wink

[porphyry5]

Just add my assumption (for using SetFilePointer with distance 0 and FILE_BEGIN) that your content is not shorter after you modified it ;-)

It is a straight one for one substitution in this case, so no problem; but I'll note that point for future reference.

[porphyry5]

hmmmm,

> On my part for assuming it was obvious that I wanted to avoid unnecessarily closing and reopening the file; on Donkey's part for assuming that that was what I wanted to do.

Understand that while many of our members are wizards, they are not yet mind readers and with any unclear questions they have to make assumptions about what your intent may be. Instead of giving lip to a member who had tried to comprehend what you were after and actually assist you, try better specifying your question so they don't have to make assumptions about what you are doing. File IO is in fact no big deal, its fully documented by the vendor and it has ajustments for performing a wide range of tasks. The best way to get NO answer is to be rude to people who are spending their spare time helping others.

I take your point, and I'm sure that Donkey's intentions were good, so let me say this:

Donkey, I apologize for reacting sharply when your advice didn't pan out for me; as jj2007 deduced, having then to recreate my input file provoked me to a much tarter response than was appropriate.