By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,467 Members | 1,308 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,467 IT Pros & Developers. It's quick & easy.

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

P: n/a
Thanks for any advice.

~ CP

Oct 18 '08 #1
Share this Question
Share on Google+
18 Replies


P: n/a
"Coffee Pot" <no****@nospam.comwrote in message
Thanks for any advice.
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.

Oct 18 '08 #2

P: n/a
"Malcolm McLean" <re*******@btinternet.comwrites:
"Coffee Pot" <no****@nospam.comwrote in message
>Thanks for any advice.
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.
Oct 18 '08 #3

P: n/a
Nate Eldredge <na**@vulcan.lanwrites:
"Malcolm McLean" <re*******@btinternet.comwrites:
>"Coffee Pot" <no****@nospam.comwrote in message
>>Thanks for any advice.
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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Oct 19 '08 #4

P: n/a
On 18 Oct 2008 at 22:12, Malcolm McLean wrote:
"Coffee Pot" <no****@nospam.comwrote in message
>Thanks for any advice.
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.

Oct 19 '08 #5

P: n/a
Antoninus Twink wrote, On 19/10/08 08:40:
On 18 Oct 2008 at 22:12, Malcolm McLean wrote:
>"Coffee Pot" <no****@nospam.comwrote in message
>>Thanks for any advice.
I don't know about Windows specifically but generally you need to
close the file or the attempted deletion will fail.
<snip>
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.
--
Flash Gordon
If spamming me sent it to sm**@spam.causeway.com
If emailing me use my reply-to address
See the comp.lang.c Wiki hosted by me at http://clc-wiki.net/
Oct 19 '08 #6

P: n/a
Coffee Pot wrote:
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.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Oct 19 '08 #7

P: n/a
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.

Oct 19 '08 #8

P: n/a
Coffee Pot wrote:
>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.

BTW AFAIK the above code isn't guaranteed to work on Linux/Unix either,
if the app crashed between the fopen and the unlink.
--
Mark McIntyre

CLC FAQ <http://c-faq.com/>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
Oct 19 '08 #9

P: n/a
Mark McIntyre <ma**********@TROUSERSspamcop.netwrites:
Coffee Pot wrote:
>>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".

--
Ben.
Oct 19 '08 #10

P: n/a
jacob navia <ja***@nospam.comwrites:
Coffee Pot wrote:
>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.
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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Oct 19 '08 #11

P: n/a
Ben Bacarisse wrote:
Mark McIntyre <ma**********@TROUSERSspamcop.netwrites:
>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...
>As has already been suggested, you need to ask in a windows
programming group.

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?
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.

>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.
Agreed, but i suspect its at least as likely the file will get used
before being unlink()ed, so....

--
Mark McIntyre

CLC FAQ <http://c-faq.com/>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
Oct 19 '08 #12

P: n/a
Mark McIntyre <ma**********@TROUSERSspamcop.netwrites:
Ben Bacarisse wrote:
>Mark McIntyre <ma**********@TROUSERSspamcop.netwrites:
>>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.
>>As has already been suggested, you need to ask in a windows
programming group.

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?

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

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.

--
Ben.
Oct 19 '08 #13

P: n/a
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
Oct 19 '08 #14

P: n/a
Ben Bacarisse wrote:
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.
*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.
All I am suggesting is that tmpfile should be the first answer when
someone posts this question here.
I'd agree, except that his original question wasn't about tmpfile, and
when he clarified what he wanted, tmpfile didn't fit the bill !
>Is there any reason to think that
tmpfile does not do what the OP needs when the program terminates
abnormally?
Take a look in the %temp% directory just after crash-rebooting a Windows
PC by pulling the power cable.
Maybe I am being overly generous to Windows C
implementation, but surely if it can be done at all, tmpfile will do
it.
??? You're having a laugh, surely.

--
Mark McIntyre

CLC FAQ <http://c-faq.com/>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
Oct 19 '08 #15

P: n/a
Willem wrote:
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.
Kinda depends what he's trying to do.
(As you may or may not know, as long as the unlinked file remains open,
you can still use it.)
Of course you know that behaviour is entirely OS-specific.

--
Mark McIntyre

CLC FAQ <http://c-faq.com/>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
Oct 19 '08 #16

P: n/a
Mark McIntyre <ma**********@TROUSERSspamcop.netwrites:
Ben Bacarisse wrote:
>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.

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

<snip>
>>Is there any reason to think that
tmpfile does not do what the OP needs when the program terminates
abnormally?

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.
> Maybe I am being overly generous to Windows C
implementation, but surely if it can be done at all, tmpfile will do
it.

??? 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.

--
Ben.
Oct 19 '08 #17

P: n/a
Ben Bacarisse wrote:
Mark McIntyre <ma**********@TROUSERSspamcop.netwrites:
>Ben Bacarisse wrote:
>>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.
*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).
My point, such as it is, was that your choice required you to guess that
the OP a) realised his existing code didn't necessarily do what he
thought and b) would be happy with the same risk on Windows.
>> Maybe I am being overly generous to Windows C
implementation, but surely if it can be done at all, tmpfile will do
it.
??? 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.
There /is/ no 'right thing'.
Oct 19 '08 #18

P: n/a
Willem wrote:
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.)
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.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
Oct 19 '08 #19

This discussion thread is closed

Replies have been disabled for this discussion.