renaming an open file ?

[R.Wieser]

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

[Charlie Gibbs]

Post by R.Wieser
Hello all,
A program of mine uses
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.

Post by R.Wieser
Remark: Windows XP sp3

Same here. Works on all later versions too.

[R.Wieser]

Charlie,

Post by Charlie Gibbs
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.

Post by Charlie Gibbs
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)

Post by Charlie Gibbs
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

[JJ]

Post by R.Wieser
Hello all,
A program of mine uses
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.

[R.Wieser]

JJ,

Post by JJ

Post by R.Wieser
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.

Post by JJ
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). :-|

Post by JJ
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

[JJ]

Post by R.Wieser

Post by JJ
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.

Post by R.Wieser
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.

[R.Wieser]

JJ,

Post by 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

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. :-)

Post by JJ
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.

Post by JJ
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.

Post by JJ

Post by R.Wieser
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).

Post by JJ
"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