C Delete opened file

This is a discussion on C Delete opened file within the C Programming forums, part of the General Programming Boards category; If you do 3 then 4, you are opening [1] the file twice and loosing the first handle. So that ...

I'm pretty sure that in 32-bit Windows, a handle is a 32-bit Unsigned, so printf using %u should allow you to print a handle [actually, in general, a handle is actually the address of the kernel data structure representing the resource that the handle represents - makes it easy to access for the kernel].

Yes, createfile, whether you do CREATE_NEW or OPEN_EXISTING will "open" the file.

That will only allow the file to be opened by another (or the same) process for reading/writing - not allow someone to delete a file that is held open, and since the first handle is lost when the second step of the reproduction is done, it's not EVER going to be closed (unless we exit the app).

Oops. I misworded. I did not mean write to file, but actually delete or truncate an open file.

But you are not deleting or truncating an open file - you are just removing the directory entry for it. And you can only do that on files that are:
- Not locked.
- Available for you to modify/remove anyways.

It is not a security hole, because any files that affect the system security, assuming the system is intended to be secure anyways, are not accessible by non-trusted users. If trusted users are sabotaging the system they are trusted to use - then you have misapplied trust, and it usually is not something you are allowed to do according to the employment contract - that is, you get the sack if it's intentional, and a stern warning if it was a mistake.

But the point was that being able to delete a file that is open by a process can have bad effects. But it seems that no such thing can be done, but there was a claim that it could be, to which I responded it seemed strange.

That will only allow the file to be opened by another (or the same) process for reading/writing - not allow someone to delete a file that is held open, and since the first handle is lost when the second step of the reproduction is done, it's not EVER going to be closed (unless we exit the app).

--
Mats

I think that's more relevent to his menuing system. For instance, if the file does not exist, then option 4 (open file) should not be available. Thus, requiring the user to select option 3 (create file). On the other hand, if the file exists, Option 4 (open file) should be available and Option 3 (create file) should not be available.

If the user tries to open the file prior to creating the file, the app will indicate that it cannot open the file. But the OP poster doesn't check to verify that the file is already open in the Open file #4 option. So, the OP should either do more error checking or make the menu system more user friendly.

The end user may have to rethink how he's using CreateFile. But anyway, no matter how he uses CreateFile, he'll still need the additional attribute.

He may want to enhance his menuing system to only allow relevant options. For instance, assuming that the OP poster starts using an array of file handles, if all files are closed, there is no reason to give the end user the option to close the file. Same thing for deleting the files. The menuing system should provide a means of guidance to the end user for making relevant decisions.

But the point was that being able to delete a file that is open by a process can have bad effects. But it seems that no such thing can be done, but there was a claim that it could be, to which I responded it seemed strange.

It can be in the sense that the directory entry goes away - you can even create a new file to replace the previous file (e.g. copy a file onto the same name as an existing open one). But only if you have the right permissions and the file is not locked, of course.

Further, the file itself still stays on the disk (but no longer available to open again). It is different from Windows, where opening a file normally prevents all others from doing anything to that file - which means for example that you can't replace an existing executable with another executable or replace a script-file that some executable is using, without shutting down the executable.

I think that's more relevent to his menuing system. For instance, if the file does not exist, then option 4 (open file) should not be available. Thus, requiring the user to select option 3 (create file). On the other hand, if the file exists, Option 4 (open file) should be available and Option 3 (create file) should not be available.

Yes, of course, a clever menu system that only allows you to do things that are meaningful is definitely a good idea. However, I think the OP didn't understand the API itself - which was the original problem - the file is opened twice by the application, and the handle from the first open (create) is lost, thus it can't be closed.