Sometimes unable to delete it

Why am I sometimes able to delete a music file even when its playing in one music player but sometimes unable in another media player ?
The error is "The file is in use". What does windows do to keep control of file foresics :( ?

Thank you

Read about CreateFile and FILE_SHARE_DELETE here.

And Michael Geary to Earth (and vice versa) blog on Use FILE_SHARE_DELETE in your shell extension for more infrmation.

- petter

Quote:

---

Originally Posted by Mattrang

What does windows do to keep control of file foresics :( ?

---

Well, Windows can't just throw what it is using. It is called a filelock. Basically, you don't just throw away what you are using.

You say that you can delete a file with a media player playing it? What media player is this? Is it possible that this media player caches the media stream?

Quote:

---

Originally Posted by peejavery

Is it possible that this media player caches the media stream?

---

I think that is a valid explanation. For e.g. open a text file in notepad and then delete it from its location without closing the notepad. You will be surprised that it deletes but notepad still shows the contents! maybe its the buffering thing that comes into play here.
In such a case you won't be able to stop and re-play the song if you have deleted it from your system.

Quote:

---

Originally Posted by peejarvey

You say that you can delete a file with a media player playing it? What media player is this? Is it possible that this media player caches the media stream?

---

How Window Media Player handles this I'm not sure, but if a file is created/opened with the FILE_SHARE_DELETE setting the file can be moved, renamed and deleted and still the application will be able to see the original file (as long a it don't close the file handle.)

- petter

It must be buffered into memory before it can be deleted. You can load a file into memory, and then delete the file while you are also playing it's copy.

Consider this example, no buffering here:

Code:

---

#include <windows.h>
#include <iostream>

int _tmain(int argc, _TCHAR* argv[])
{
    HANDLE hFile;

    // open file
    hFile = CreateFile(_T("somefile.txt"),
        GENERIC_READ | GENERIC_WRITE,
        FILE_SHARE_READ | FILE_SHARE_DELETE,
        NULL,
        CREATE_ALWAYS,
        FILE_ATTRIBUTE_NORMAL,
        NULL);

    // write some data to it
    char pcData[256] = "This is the data.";
    DWORD dwWritten;
    if (!WriteFile(hFile, pcData, (DWORD) strlen(pcData), &dwWritten, NULL))
    {
        // failed
        return 0;
    }

    ZeroMemory(pcData, 256);

    // wait for user to delete/move/rename file
    std::cout << "Delete the file (in 20 seconds)..." << std::endl;
    Sleep(20000);

    // seek to beginning of file
    SetFilePointer(hFile, 0, 0, FILE_BEGIN);

    // read the data
    DWORD dwRead;
    if (!ReadFile(hFile, pcData, 100, &dwRead, NULL))
    {
        // failed
        return 0;
    }

    std::cout << "Read " << std::dec << dwRead << " bytes:" << std::endl;
    std::cout << pcData << std::endl;
       
    CloseHandle(hFile);

    return 0;
}

---

This example should work just fine if someone rename/moves/deletes the file during the 'sleep'. If you rename/move the file our application will still be able to read the contents. If we attempt to delete the file then (without errors) the file will be marked for deletion, and then deleted as soon as our application is done with it.

- petter

Sth different but quite relevant (in my opinion). In windows XP there is that area nexto each explorer window that plots information about files etc. When a wav file is clicked windows explorer shows information for that file (e.g. duration). I have noticed that the way the file is opened at thad point is very annoying (in my opinion). I used to work on a project for audio signal processing and i had a simple C program writing/reading wav files. If I had forgoten a wav file "clicked" in a window, and then I runned my application the fopen() command returned null. So I had to select another media file to be able to read/write to the previous one.