C Delete opened file

Hi,

I am in the early stages of learning C (previously coded in java, PHP etc.).

The code below is a simple menu which enables you to:
create, delete, open and close a file.

The problem i have is if you choose to create the file, then open it, it is then not possible to delete it (gives error 32).
If you delete without opening it works fine or if you restart the program and then delete the file that was created in the last run it is also ok. Just seems you cant create, open and delete in same operation.

Any input would be helpful.

Code:

---

// for Win Xp Pro
#define _WIN32_WINNT 0x0501
#include <windows.h>
#include <stdio.h>

int main()
{
  HANDLE hFile;
  char fname[30] = "C:\\testfile.txt";
  int menuOption;

do {
      printf("\n");
      printf("0) Exit\n");
      printf("1) Close File\n");
      printf("2) Delete File\n");
      printf("3) Create File\n");
      printf("4) Open File\n");
      scanf("%d", &menuOption);

    switch(menuOption)
    {
        case 0 :
            break;
        case 1 :
            //close option
            if(CloseHandle(hFile) != 0)
              printf("CloseHandle() succeeded!\n");
            else printf("CloseHandle() failed!\n");
            break;
        case 2 :
            //delete option
            if(CloseHandle(hFile) != 0)
              printf("CloseHandle() succeeded!\n");
            else printf("%s could not be closed! error %u\n", fname, GetLastError());

            if(DeleteFile(fname) != 0)
              printf("%s file successfully deleted!\n", fname);
            else printf("%s could not be deleted! error %u\n", fname, GetLastError());
            break;
        case 3 :
            //create option
            hFile = CreateFile(fname,              // file to be opened
                                GENERIC_WRITE,      // open for writing
                                FILE_SHARE_WRITE,  // share for writing
                                NULL,              // default security
                                CREATE_NEW,        // create new file only
                                FILE_ATTRIBUTE_NORMAL |FILE_ATTRIBUTE_ARCHIVE | SECURITY_IMPERSONATION,
                                                    // normal file archive and impersonate client
                                NULL);              // no attribute template

            if(hFile == INVALID_HANDLE_VALUE)
              printf("Could not create %s file, error %u.\n", fname, GetLastError());
            else printf("%s file created successfully, error if any, %u.\n", fname, GetLastError());
            break;
        case 4 :
            //open option
            hFile = CreateFile(fname,            // file to create
                      GENERIC_WRITE,            // open for writing
                      FILE_SHARE_WRITE,          // allow write share
                      NULL,                      // default security
                      OPEN_EXISTING,            // opens a file
                      FILE_ATTRIBUTE_NORMAL |FILE_ATTRIBUTE_ARCHIVE | SECURITY_IMPERSONATION,
                      NULL);                    // no attribute template

            if(hFile == INVALID_HANDLE_VALUE)
              printf("Could not open %s file, error %u.\n", fname, GetLastError());
            else printf("%s file opened successfully, error if any, %u.\n", fname, GetLastError());
            break;
        default :
            //error message
            printf("Sorry but %d is not a valid option!", menuOption);
            break;
    }
 } while (menuOption !=0);

  return 0;
}

---

Thanks,
Gid

It's all pretty complex with permissions, http://msdn.microsoft.com/en-us/libr...15(VS.85).aspx

Basically see the "Remarks" section.

Quote:

---

To delete or rename a file, you must have either delete permission on the file, or delete child permission in the parent directory.

---

> Just seems you cant create, open and delete in same operation.
I hope you don't mean create, open then delete... You can't open the same file twice (or at least you might not be able to :)).

Mods: this probably belongs in Windows programming.

I have tried to give the FILE_SHARE_WRITE | READ | DELETE permissions but that seems to error.

If you run the above code it allows you to create file, when you then open file you get a success message. delete then fails. (options 3, 4 then 2)

if instead you just choose (options 3 and 2) it creates successfully and then deletes successfully.

Note: the above was coded and compiled in code::blocks.

Of course you cannot delete it after you've opened it. The same applies to any language, because it's enforced by the OS.
As long as there is an application that has an open handle to the file, you can't delete it.

And you should probably use fopen/fclose instead of CreateFile. More portable and not so horrible.

Quote:

---

Originally Posted by Elysia

Of course you cannot delete it after you've opened it. The same applies to any language, because it's enforced by the OS.
As long as there is an application that has an open handle to the file, you can't delete it.

---

That would of course depend on the operating systems. Some *nix flavours allow some accounts to delete open files for example.
Handy for truncating logfiles, just delete the file and a well-written server will just create a new one with the same name.

Error 32 means "Sharing Violation", so you are trying to delete the file whilst it is in use, according to Windows.

What exact steps are you doing to cause this to happen? It appears to work on my machine with your code - but maybe I'm missing something.

--
Mats

Quote:

---

Originally Posted by jwenting

That would of course depend on the operating systems. Some *nix flavours allow some accounts to delete open files for example.
Handy for truncating logfiles, just delete the file and a well-written server will just create a new one with the same name.

---

Which is just silly to me. That would allow programs to delete or truncate some critical files, which the application is keeping open on purpose to block access to it.
Sometimes I don't get Linux at all, with all its security & all that.
If you can write to open files, it can even be a security risk.

Quote:

---

Originally Posted by jwenting

That would of course depend on the operating systems. Some *nix flavours allow some accounts to delete open files for example.
Handy for truncating logfiles, just delete the file and a well-written server will just create a new one with the same name.

---

Actually, it continues writing to the existing (now invisible) file until the server is restarted (or until it closes and opens the file for some other reason). And as far as I know, it has nothing to do with what account you have - that will only affect what files you can delete, but not whether you can delete one that is open or not.

Edit: I'm pretty sure that a file CAN be opened in such a way that it's not allowed to be deleted - but a file opened with standard parameters to "fopen" can certainly be deleted directly by anyone who has permission to delete that file. Of course, lock-files for servers and such are usually opened by root or some other "non-user-accessible" account - so that prevents a random malicious user from deleting the file. If the user has root-access, then nothing is safe, right?

--
Mats

Sorry,

Just to clarify, the delete procedure performs a close on the handle before attempting the delete.
This close succeeds but the subsequent delete fails.

When running this on my system the following options replicate my error.

Select option 3.
Select option 4.
Select option 2.

I am running WinXP sp2.

Cheers,
Gid

Quote:

---

Originally Posted by matsp

Edit: I'm pretty sure that a file CAN be opened in such a way that it's not allowed to be deleted - but a file opened with standard parameters to "fopen" can certainly be deleted directly by anyone who has permission to delete that file. Of course, lock-files for servers and such are usually opened by root or some other "non-user-accessible" account - so that prevents a random malicious user from deleting the file. If the user has root-access, then nothing is safe, right?

---

Is that for Linux, then? Because default parameters for fopen on Windows is exclusive - non-deletable. I don't know if it is possible to delete an open file, but it is possible to allow other processes to read and write to the file at the same time.

From my limited experience it seems to me that one of the following is happening:

1) the code used to open the file (switch case 4) is changing the permissions in some way as to restrict deletion.

2) The code to close the file (switch case 2) that is as follows: if(CloseHandle(hFile) != 0)
Does not actually close the file like it says.

> If you can write to open files, it can even be a security risk.
That's what flockfile() is for... Bang supposed security risk gone (I can't even see how there would be one anyway...)

Quote:

---

Originally Posted by matsp

Actually, it continues writing to the existing (now invisible) file until the server is restarted (or until it closes and opens the file for some other reason). And as far as I know, it has nothing to do with what account you have - that will only affect what files you can delete, but not whether you can delete one that is open or not.
--
Mats

---

The contents of the file that existed before are however deleted, so the effect is the same.
Were nothing to be written to the file after the rm command (including a close command) it would be a goner.

Of course the account only determines whether you have delete access at all, just thought to mention it to prevent someone asking why file XXX cannot be deleted by him but YYYY can :)

Quote:

---

Originally Posted by zacs7

> If you can write to open files, it can even be a security risk.
That's what flockfile() is for... Bang supposed security risk gone (I can't even see how there would be one anyway...)

---

If you could write to an executable that's being read by the operating system at that moment you could inject code in it that would be executed as well.
Potential security risk I guess.

Highly theoretical of course, far better to intercept the process after it's been loaded into memory and been validated as safe by virus scanners and change the instruction sequence there.

are we getting off topic here :-P

Any ideas whether my 2 possible reasons for this error are correct and/or how to resolve?

If you do 3 then 4, you are opening [1] the file twice and loosing the first handle. So that handle from createfile can only be closed by exiting the application itself - as the handle for it is lost.

[1] Ok, technically, creating, then opening - but that's two handles opened for the same file - print out the handle after you've called CreateFile in each case.

--
Mats

ahhh,
Didn't realise it was possible to have 2 handles open for the same file. Or even that the create process leaves it in an open state.

Will look into how to print the handle (as output is all different from what i'm used to in Java).
Will also see about placing a check on the open option to check if the file handle is already open.

Thanks matsp!!

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.

--
Mats

Code:

---

                        case 3 :
                                //create option
                                hFile = CreateFile(fname,              // file to be opened
                                        GENERIC_WRITE,      // open for writing
                                        FILE_SHARE_DELETE | FILE_SHARE_WRITE,  // share for writing                                       
                                        NULL,              // default security
                                        CREATE_NEW,        // create new file only
                                        FILE_ATTRIBUTE_NORMAL |FILE_ATTRIBUTE_ARCHIVE | SECURITY_IMPERSONATION,
                                        // normal file archive and impersonate client
                                        NULL);              // no attribute template

---

Quote:

---

Originally Posted by BobS0327

Code:

---

                        case 3 :
                                //create option
                                hFile = CreateFile(fname,              // file to be opened
                                        GENERIC_WRITE,      // open for writing
                                        FILE_SHARE_DELETE | FILE_SHARE_WRITE,  // share for writing                                       
                                        NULL,              // default security
                                        CREATE_NEW,        // create new file only
                                        FILE_ATTRIBUTE_NORMAL |FILE_ATTRIBUTE_ARCHIVE | SECURITY_IMPERSONATION,
                                        // normal file archive and impersonate client
                                        NULL);              // no attribute template

---

---

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

Quote:

---

Originally Posted by zacs7

> If you can write to open files, it can even be a security risk.
That's what flockfile() is for... Bang supposed security risk gone (I can't even see how there would be one anyway...)

---

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

Quote:

---

Originally Posted by Elysia

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.

--
Mats

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.

Quote:

---

Originally Posted by matsp

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.

Quote:

---

Originally Posted by Elysia

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.

--
Mats

Quote:

---

Originally Posted by BobS0327

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.

--
Mats