How can I unlink/delete an open file in Windows?

N

Nate Eldredge

Malcolm McLean said:
I don't know about Windows specifically but generally you need to
close the file or the attempted deletion will fail.

system("del C:\\path\\to\\file");

will delete.

To keep this semi-on-topic, standard C provides the remove() function.
However the results are "implementation defined" if the file is open, so
to be portable you would need to close it first. I also don't know what
Windows implementations usually do but I think they might fail if the
file is open. See the documentation for your C compiler / library.

As a side note, the "generally" may be an overstatement; on Unix it is
entirely legal to remove an open file. The file will be "unlinked" (so
it no longer appears in the filesystem, unless there are other links to
it) but the data will remain on the disk, accessible to whoever has it
open, until they all close it, at which point the data is actually
deleted. This is frequently a useful feature. I do not know if Windows
provides anything equivalent but my guess is no; it's my impression that
the Windows philosophy is to forbid you from messing with an open file.
 
K

Keith Thompson

Nate Eldredge said:
Malcolm McLean said:
I don't know about Windows specifically but
[...]

To keep this semi-on-topic, standard C provides the remove() function.
However the results are "implementation defined" if the file is open, so
to be portable you would need to close it first. I also don't know what
Windows implementations usually do but
[...]

The above answers should be a strong clue that this is not the best
place for your question. (I don't know

Standard C provides the remove() function; how it behaves if the file
is open depends on the system.

If you want Windows-specific information (which appears to be what you
need), try asking in comp.os.ms-windows.programmer.win32. Wherever
you post, I suggest including the question in the body of your
article.
 
A

Antoninus Twink

I don't know about Windows specifically but generally you need to
close the file or the attempted deletion will fail.

I wonder what the rational for this behavior was - it does seem more
like a bug than a feature.

It's been a while since I used Windows, but I think the only reliable
way is to arrange for the file to be deleted on the next reboot. I think
that's what installers do to get rid of shared libraries that might
still be in use, etc.

I guess you could do this by appending a line

DEL c:\path\to\file

to the AUTOEXEC.BAT file (here DEL is the DOS equivalent of rm), or
probably there's some way of hooking into the registry to achieve the
same effect.
 
F

Flash Gordon

Antoninus Twink wrote, On 19/10/08 08:40:
I guess you could do this by appending a line

DEL c:\path\to\file

to the AUTOEXEC.BAT file (here DEL is the DOS equivalent of rm), or

As usual Antoninus has guessed something that is very poor advice.
probably there's some way of hooking into the registry to achieve the
same effect.

He has also failed to mention the need to go else where to discus what
might be slightly closer to a possible solution, although one with
server restrictions. As mentioned else-where the best advice is to
discus the problem in a Windows group. When doing so also say *why* you
want to delete an open file as this might have a big impact on the best
solution.
 
J

jacob navia

Coffee said:
Thanks for any advice.

~ CP
The DeleteFileTransacted function marks a file for deletion on close.
Therefore, the file deletion does not occur until the last handle to the
file is closed.

You should get the documentation, it is freely available by
Microsoft. Download the SDK.
 
C

Coffee Pot

When doing so also say *why* you
want to delete an open file as this might have a big impact on the best
solution.

Thanks for the replies.

Basically I am trying to port the following UNIX code to Windows.

FILE *tmpfil;
char template[]="/tmp/XXXXXX";
mktemp(template);
tmpfil = fopen(template, "w+");
unlink(template);

This guarantees that the temporary file will be removed at the end of
execution even if the program terminates abnormally.
 
B

Ben Bacarisse

Mark McIntyre said:
Coffee said:
When doing so also say *why* you
want to delete an open file as this might have a big impact on the best
solution.

Thanks for the replies.

Basically I am trying to port the following UNIX code to Windows.

FILE *tmpfil;
char template[]="/tmp/XXXXXX";
mktemp(template);
tmpfil = fopen(template, "w+");
unlink(template);

This guarantees that the temporary file will be removed at the end of
execution even if the program terminates abnormally.

As has already been suggested, you need to ask in a windows
programming group. I strongly suspect windows has its own mechanism
for creating and clearing up temp files which will work very similarly
but using platform-specific functions.

I can't see why. Surely the standard C function

include <stdio.h>
FILE *tmpfile(void);

The tmpfile function creates a temporary binary file that is
different from any other existing file and that will automatically
be removed when it is closed or at program termination. If the
program terminates abnormally, whether an open temporary file is
removed is implementation-defined. The file is opened for update
with "wb+" mode.

is what the OP needs?
BTW AFAIK the above code isn't guaranteed to work on Linux/Unix
either, if the app crashed between the fopen and the unlink.

I suspect the unlink follows the fopen (this is an old but common
idiom) so such a crash is not likely. If one were to give any
off-topic advice about the Unix code it would be: "don't use mktemp --
it is a ghoul from the past and there is no point in trying to
replicate its various faults in new code".
 
K

Keith Thompson

jacob navia said:
The DeleteFileTransacted function marks a file for deletion on
close. Therefore, the file deletion does not occur until the last
handle to the file is closed.

That might be the best possible answer to your question. But since
most of us here aren't Windows experts, you're not going to get very
many other suggestions, so you can't really tell.
You should get the documentation, it is freely available by
Microsoft. Download the SDK.

And you should ask in a newsgroup that discusses Windows programming.
 
B

Ben Bacarisse

Mark McIntyre said:
Ben said:
Mark McIntyre said:
Coffee Pot wrote:
Basically I am trying to port the following UNIX code to Windows.

FILE *tmpfil;
char template[]="/tmp/XXXXXX";
mktemp(template);
tmpfil = fopen(template, "w+");
unlink(template);

This guarantees that the temporary file will be removed at the end of
execution even if the program terminates abnormally.

Note this sentence...

Yes, but we both know that this is not true, in general, for the above
code so it seems unlikely that the OP really needs that as a hard and
fast guarantee. If the program did need that behaviour, then the
original code would not do the bad mktemp/unlink trick.
From his post above what he wanted was a guarantee the file would be
cleaned up. As the section you quoted made clear, for tmpfile() this
is implementation defined.

All I am suggesting is that tmpfile should be the first answer when
someone posts this question here. Is there any reason to think that
tmpfile does not do what the OP needs when the program terminates
abnormally? Maybe I am being overly generous to Windows C
implementation, but surely if it can be done at all, tmpfile will do
it.
Agreed, but i suspect its at least as likely the file will get used
before being unlink()ed, so....

I think what they posted was the code they are porting (at least I
can't see any reason to assume otherwise at this stage). I.e. the
unlink follows immediately after the fopen.
 
W

Willem

Mark McIntyre wrote:
) Ben Bacarisse wrote:
)> I suspect the unlink follows the fopen (this is an old but common
)> idiom) so such a crash is not likely.
)
) Agreed, but i suspect its at least as likely the file will get used
) before being unlink()ed, so....

Doubtful. The usual trick is to unlink() it directly after open()ing it.

(As you may or may not know, as long as the unlinked file remains open,
you can still use it.)


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
 
B

Ben Bacarisse

Mark McIntyre said:
*shrug*. You may be right, but I dont propose to second-guess the
OP. He said he wanted a guaranteed method, C doesn't provide one, his
OS may, this isn't the place to ask about that.

There is no need to second guess. They said they were porting code X
and they wanted behaviour Y. Code X does not have behaviour Y. You
chose one way to answer (believe they want Y) I went for the other
(they want something as good as or better than code X).

Take a look in the %temp% directory just after crash-rebooting a
Windows PC by pulling the power cable.

How can I know which of these stem from tmpfile not doing what the OP
wanted? I was genuinely asking (as a marginally on-topic QOI
question) if tmpfile leaves something visible when the plug is pulled
on MS Windows. Given the system specific comments already posted, a
quick "yes" or "no" from someone who knows would not be unreasonable.
??? You're having a laugh, surely.

Nope! I know some very good people who work for MS, and it only takes
one to get tmpfile to do the right thing.
 
C

CBFalconer

Willem said:
Doubtful. The usual trick is to unlink() it directly after
open()ing it.

(As you may or may not know, as long as the unlinked file
remains open, you can still use it.)

Under Unix/Linux, using their own file systems. Not necessarily
elsewhere. This doesn't belong on c.l.c, but on some group dealing
with the OPs system.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top