🚀 go-pugleaf

> > ...I almost never use FILE_SHARE_*  on a file I
> > am creating...
>
> ... We normally do that because engineers like to
> look at what's coming off the disk before imaging has
> finished. ...

A sharing flag suggests that Windows' buffering layer keep
copies around for the sharing users.  If I experienced the
symptoms you describe, my first reaction would be to do
whatever it takes to force the write to be with as little
system-supplied buffering as possible.

If your guys like to see the data that a WriteFile writes
even when they already have access to the program buffer
containing the source data whose address was passed to
WriteFile, consider opening a second, echo file on the local
disk or pipe which has sharing enabled and issuing another
WriteFile to it AFTER the real WriteFile call.

I did not mention this before because I suspected it would be
a burden in your case and I do not know how it would be
handled when the target is on a network, but most of the
time I use FILE_FLAG_WRITE_THROUGH I also use
FILE_FLAG_NO_BUFFERING.  The latter requires the
address of the source be on sector sized boundaries and
the size of the write be an integral multiple of that.

While the help (or at least as I remember it) implies that
you might have to allocate a special buffer for this to force
the alignment, sector sizes are a power of 2 and the
Windows' implementation pretty much requires that any
virtual address in your program which is so aligned (any
address whose numeric value mod that power of 2 is zero),
will map to a physical address which is so aligned.  In my
case I don't bother with the allocation or with determining
the sector size.  I align on a 4K boundary which should
cover any conceivable sector size (I cannot remember a
disk which did not have 512 byte sectors other than floppies
which had power of two sub-multiples of that.)

.  Ed

> Andrue Cope wrote in message
> news:41b8159d$1@newsgroups.borland.com...
>
> > Have you tried specifying FILE_FLAG_WRITE_THROUGH
> > and callingFlushFileBuffers?
>
> We didn't find either of those yesterday - thanks, I'll try them
> today.
>
> > Also, I almost never use FILE_SHARE_*  ...
>
> We normally do that because engineers like to look at
> what's coming off the disk before imaging has finished. In
> this case the tool is primarily for forensic work so the
> disks can be assumed to be good and we can forgoe
> this feature.