Does GetOpenFileName() lock the directory?

[kuang Cao]

Hi,

I am working on a feature as described below:
1. Use the GetOpenFileName() to select a file in a directory and open the file.
2. The user can then make changes to the content of the file.
3. Based on the changes, all the files in the same directory as the opened file will be renamed, as well as the containing directory.

Now here comes the problem, I had no problem renaming all the files, even the file that was opened, but when I tried to rename the containing directory, it failed with a share violation.

I then tried some sample code from a book, but the same thing happened even if I just select a file but don't do anything with the file, i.e, not opening the file.

The following is the relevant sample code for selecting the file:


ofn.lStructSize = sizeof (OPENFILENAME) ;
ofn.hwndOwner = hwnd ;
ofn.hInstance = NULL ;
ofn.lpstrFilter = szFilter ;
ofn.lpstrCustomFilter = NULL ;
ofn.nMaxCustFilter = 0 ;
ofn.nFilterIndex = 0 ;
ofn.lpstrFile = pstrFileName ;
ofn.nMaxFile = MAX_PATH ;
ofn.lpstrFileTitle = pstrTitleName ;
ofn.nMaxFileTitle = MAX_PATH ;
ofn.lpstrInitialDir = NULL ;
ofn.lpstrTitle = NULL ;
ofn.Flags = 0 ; // Set in Open and Close functions
ofn.nFileOffset = 0 ;
ofn.nFileExtension = 0 ;
ofn.lpstrDefExt = TEXT ("txt") ;
ofn.lCustData = 0L ;
ofn.lpfnHook = NULL ;
ofn.lpTemplateName = NULL ;
ofn.Flags = OFN_HIDEREADONLY | OFN_CREATEPROMPT ;

GetOpenFileName (&ofn) ;


Thanks a lot for your help.

[ovidiucucu]

[ Moved thread ]

[kuang Cao]

I just tried to check file handles using the program ProcessExplorer from here:

http://www.sysinternals.com/ntw2k/freeware/procexp.shtml

And for sure the program has a handle open for the directory, once I manually closed that handle from ProcessExplorer, I can rename the directory fine.

So I guess the question is how to release that handle from within the program. Thanks a lot.

[kuang Cao]

Never mind, OFN_NOCHANGEDIR does the trick.

[Darkeyes_z]

I was having a similar issue with GetOpenFileName(), I was about to write my own dialog class.

I am using GetOpenFileName() on the GUI of my program and then passing the filename to fopen(). All works fine until my program tries to do a fopen() with out GetOpenFileName() around it.... for some reason it was locking all the files in the directory.

OFN_NOCHANGEDIR does the trick.... really weird. Also, OFN_NOCHANGEDIR says unsupported in the MSDN docs. Got to love it.

Anyway, if anyone else is having a locking problem or some fopen() fails if not first calling GetOpenFileName() try ORing OFN_NOCHANGEDIR in the ofn.Flags

Hope this helps,
Thomas McDonley

[Darkeyes_z]

After doing a little research on the flag I found out what it is for and why it is 'not supported'.

OFN_NOCHANGEDIR makes sure that the PWD(present working directory) doesn't change when the user opens a file.

So if you do GetOpenFileName() on "./subfolder"... it will work for all calls to GetOpenFileName... it will change the PWD... so calls to fopen() will really be looking for "./subfolder/subfolder"

It's listed as not supported because some versions of windows don't either remember or record the PWD with GetOpenFileName()....

Solution: Never assume GetOpenFileName() leaves the PWD alone. Honestly I would save it before and restore it after a GetOpenFileName or GetSaveFileName call