Hello all,

A program of mine uses

CreateFile,offset [@@FLE_Temp],GENERIC_WRITE or GENERIC_READ,
FILE_SHARE_READ, 0, CREATE_ALWAYS, FILE_ATTRIBUTE_TEMPORARY or FILE_FLAG_DELETE_ON_CLOSE, 0

to open a temporary, auto-deleting file.

But sometimes have the need to save the contents of that temporary file.

I've tried MoveFile as well as CopyFile, but both complain about the source file being open (it is, no debate about that). As far as I know that FILE_SHARE_READ flag should have been enough, but it looks like I'm missing something ...

Anyone have an idea what I'm missing ?

Remark: Windows XP sp3

Regards,
Rudy Wieser

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-06-13, R.Wieser <address@is.invalid> wrote:

Hello all,

A program of mine uses

CreateFile,offset [@@FLE_Temp],GENERIC_WRITE or GENERIC_READ, FILE_SHARE_READ, 0, CREATE_ALWAYS, FILE_ATTRIBUTE_TEMPORARY or FILE_FLAG_DELETE_ON_CLOSE, 0

to open a temporary, auto-deleting file.

But sometimes have the need to save the contents of that temporary file.

I've tried MoveFile as well as CopyFile, but both complain about the source file being open (it is, no debate about that). As far as I know that FILE_SHARE_READ flag should have been enough, but it looks like I'm missing something ...

Anyone have an idea what I'm missing ?

You may have noticed that Windows often gets fanatically possessive
of files. The KISS principle goes a long way toward dealing with
this. As a general rule, I never use an OS-specific API when there's
something in the C run-time library that does the job. That way
my programs remain portable to other OSes. In this case I'd just
use good old fopen(), do whatever I/O I want, then fclose() the file.
At this point I'm free to rename() it, unlink() it, or just leave
it as is.

Remark: Windows XP sp3

Same here. Works on all later versions too.

--
/~\ Charlie Gibbs | The Internet is like a big city:
\ / <cgibbs@kltpzyxm.invalid> | it has plenty of bright lights and
X I'm really at ac.dekanfrus | excitement, but also dark alleys
/ \ if you read it the right way. | down which the unwary get mugged.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Charlie,

You may have noticed that Windows often gets fanatically
possessive of files.

I've seldom have had problems with it. And in this case, copying from a write-to file could, for all normal intents and purposes, mean that only a partial copy would be made - and that is for sequential writing. Imagine a
bit more complex structured file where stuff here and there must be updated
in tandem, and you could just have a copy which got the "here" change, but
not the "there" change (located before the "here"), meaning you would be
left with a broken, useless copy.

IOW, its posessivenes could be for a good reason.

The KISS principle goes a long way toward dealing with this.
As a general rule, I never use an OS-specific API when there's
something in the C run-time library that does the job.

I have the opposite POV: never use a high-level API when I can do the same
with a low-level one (and do ask me about how I dislike the "scanf" family
of functions, which I had the displeasure of trying to use to read lines
from a file and bail out if the lines formatting was bad. Heck, when you
read values from a file it even ignores line ends)

As a general rule, I never use an OS-specific API when there's
something in the C run-time library that does the job. That way
my programs remain portable to other OSes.

... as long as you recompile it for that OS and version thereof. IOW, thats /at best/ source-code portable - as long as you program with the lowest
common denominator in mind (hardware wise / capabilities).

Though the most important reason to me is that stuff gets hidden from me.
And, as an Assembly programmer, I don't really like that.

Yes, I know that I sometimes have little choice (the current OpenSSL DLLS included). :-|

Yes, I've been know to disassemble (system) DLLs (using IDA) to try to
figure out what they are actually doing. :-)

Regards,
Rudy Wieser

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 13 Jun 2024 16:45:19 +0200, R.Wieser wrote:

Hello all,

A program of mine uses

CreateFile,offset [@@FLE_Temp],GENERIC_WRITE or GENERIC_READ, FILE_SHARE_READ, 0, CREATE_ALWAYS, FILE_ATTRIBUTE_TEMPORARY or FILE_FLAG_DELETE_ON_CLOSE, 0

to open a temporary, auto-deleting file.

But sometimes have the need to save the contents of that temporary file.

I've tried MoveFile as well as CopyFile, but both complain about the source file being open (it is, no debate about that). As far as I know that FILE_SHARE_READ flag should have been enough, but it looks like I'm missing something ...

Anyone have an idea what I'm missing ?

Remark: Windows XP sp3

Regards,
Rudy Wieser

Use the FILE_SHARE_DELETE sharing flag.

But it would be pointless if you use FILE_FLAG_DELETE_ON_CLOSE. Don't use
that flag. Delete manually.

Automations helps you, but you loose some degree of controls.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

JJ,

I've tried MoveFile as well as CopyFile, but both complain about the
source file being open (it is, no debate about that). As far as I know
that FILE_SHARE_READ flag should have been enough, but it looks like
I'm missing something ...

Anyone have an idea what I'm missing ?

Use the FILE_SHARE_DELETE sharing flag.

I tried that with both the copy as well as the move.

The move does actually works, but the moved file (ofcourse?) disappears when the file-handle gets closed.

When I try a copy I got the "in use" error every time, no matter what attributes I created the temp file with.

But it would be pointless if you use FILE_FLAG_DELETE_ON_CLOSE.

You mean with a move ? Yep, found that out too.

A bit illogical to me though : why would anyone want to move a
delete-on-close file anywhere ? As such I assumed/hoped a move would cause that flag to be dropped.

Alas, it doesn't - and you cannot remove the flag thru changing the file attributes either (I tried). :-|

Don't use that flag. Delete manually.

:-) Yeah, that was what I was thinking (after all those copy/move results) too.

Than again, I just /might/ write my own file-copy routine for it. :-)

It looks like that a delete-on-close file has got a rather limited use-case. Bummer.

Thanks for the response.

Regards,
Rudy Wieser

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

JJ,

I forgot to mention that, if the file is moved, if it's moved to a
different drive, any data writtin into the file after the file was
moved, will not be applied to the moved file. e.g.:

I just tried that (I wanted to see/verify it for myself), and, under Win
XPsp3, got an error from the move function : error 203, "The system could
not find the environment option that was entered." As the target file was specified at C:\ (with the source file at D:\ ) I'm fairly sure that that environment actually exists. :-)

If the file was moved to the same drive, the moved file will have
the written data.

I was curious about it too, tested it, and noticed the same. Stands to
reason, as a move on the same (logical) drive just changes some meta-data.

I think that's the limitation of the FILE_SHARE_DELETE flag. Since
it controls whether the directory entry for the file can be modified
or not.

Moving the file to a different drive would be a copy of the directory
entry, instead of modifying the existing one.

As a hobby programmer I do not see anything outof the ordinary to have the
OS copy the file to another (local) drive and than have it alter the data it carries in the file-handle too. Than again, maybe something complex makes
that impossible. Or its just some "it has to fail the same way" legacy consideration. Who knows.

When I try a copy I got the "in use" error every time, no matter
what attributes I created the temp file with.

That would require FILE_SHARE_READ, and without FILE_FLAG_DELETE_ON_CLOSE.

:-) I did add that "share read" flag rather early on doing my tests. The
funny thing is that the copy function refuses to work, but I'm allowed to
open the (already open) file a second time (which means I could just write a copy method myself).

FILE_FLAG_DELETE_ON_CLOSE description says:
"Subsequent open requests for the file fail, unless the FILE_SHARE_DELETE share mode is specified."

I read that too. But for some reason the (OS provided!) copy function
doesn't bother with using it, and gives no way(?) to tell it to do so.

Regards,
Rudy Wieser

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 14 Jun 2024 09:34:56 +0200, R.Wieser wrote:

Use the FILE_SHARE_DELETE sharing flag.

I tried that with both the copy as well as the move.

The move does actually works, but the moved file (ofcourse?) disappears when the file-handle gets closed.

I forgot to mention that, if the file is moved, if it's moved to a different drive, any data writtin into the file after the file was moved, will not be applied to the moved file. e.g.:

1. An application create and overwrite a file (i.e. start from scratch)
using the needed flags: c:\temp\test.txt

2. The application display a message box to pause the application.

3. From outside of the application, move the file and optionally change the file name.

4. Close the message box to resume application.

5. The application write something into the file, then terminates.

If the file was moved to the same drive, the moved file will have the
written data.

If the file was moved to a different drive, the moved file will stay empty
and not have the written data.

I think that's the limitation of the FILE_SHARE_DELETE flag. Since it
controls whether the directory entry for the file can be modified or not. Moving the file to a different drive would be a copy of the directory entry, instead of modifying the existing one.

When I try a copy I got the "in use" error every time, no matter what attributes I created the temp file with.

That would require FILE_SHARE_READ, and without FILE_FLAG_DELETE_ON_CLOSE.

FILE_FLAG_DELETE_ON_CLOSE description says:
"Subsequent open requests for the file fail, unless the FILE_SHARE_DELETE
share mode is specified."

Using both FILE_FLAG_DELETE_ON_CLOSE and FILE_SHARE_DELETE, but without FILE_SHARE_READ allows file to be opened, but does not allow the file to be read.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)