photometadatahandler
-
Hi all, I've got a strange problem while trying to save a file. Accidentally it occurs, that an existing file, which will be overwritten by my application, is still opened by photometadatahandler.dll. This happens after I close the 'save file dialog' of my application. This is what I do: - OpenFileDialog (for saving file) - Select existing file - Press ok - Try to do a CreateFile The CreateFile sometimes returns INVALID_HANDLE and GetLastError shows 5=Access denied. Now I did the following as a workaround, instead of a simple CreateFile: do { myhandle = CreateFile(...); err = GetLastError(); TRACE("CreateFile handle %x error %x", myhandle, err); if(myhandle == INVALID...) Sleep(500); // try to enable other threads... }while((myhandle == INVALID...) && (some timeout condition)) My Trace output shows this: CreateFile handle ffffffff error 5 CreateFile handle ffffffff error 5 'MyApp.exe': Unloaded 'C:\Windows\System32\PhotoMetadataHandler.dll' CreateFile handle 200 error 0 The Photo..blah.dll seems to lock my file. 1. How can I wait till the photo..blah.dll is unloaded? 2. Or how can I force to unload this dll? Any thoughts? jung-kreidler
-
Hi all, I've got a strange problem while trying to save a file. Accidentally it occurs, that an existing file, which will be overwritten by my application, is still opened by photometadatahandler.dll. This happens after I close the 'save file dialog' of my application. This is what I do: - OpenFileDialog (for saving file) - Select existing file - Press ok - Try to do a CreateFile The CreateFile sometimes returns INVALID_HANDLE and GetLastError shows 5=Access denied. Now I did the following as a workaround, instead of a simple CreateFile: do { myhandle = CreateFile(...); err = GetLastError(); TRACE("CreateFile handle %x error %x", myhandle, err); if(myhandle == INVALID...) Sleep(500); // try to enable other threads... }while((myhandle == INVALID...) && (some timeout condition)) My Trace output shows this: CreateFile handle ffffffff error 5 CreateFile handle ffffffff error 5 'MyApp.exe': Unloaded 'C:\Windows\System32\PhotoMetadataHandler.dll' CreateFile handle 200 error 0 The Photo..blah.dll seems to lock my file. 1. How can I wait till the photo..blah.dll is unloaded? 2. Or how can I force to unload this dll? Any thoughts? jung-kreidler
Hi, this is my standard first reaction to the symptoms you described, it may or may not apply to your situation: if you want write or delete access (anything other than read access) to a file that just got created (by yourself or someone else, does not matter), chances are you will find the file is being accessed by some other process, and your access is not granted. The other process very likely is some server code that is there to assist you somehow. Candidates are: - anti-virus software (Norton, McAfee, whatever) - indexing software (Google Desktop, MS Office, whatever) The common thing is these packages are looking all the time for new files, so they can inspect them. Microsoft is aware of the consequences; Windows Explorer will try rename and delete attempts up to five times (with one-second interval), and only reports failure if the action continues to fail for that time. The solution: 1. either use a different file name 2. or remove all background reader candidates (bad idea) 3. or implement the retry loop as Explorer has it (use a Windows.Forms.Timer for this) :)
Luc Pattyn [Forum Guidelines] [My Articles]
- before you ask a question here, search CodeProject, then Google - the quality and detail of your question reflects on the effectiveness of the help you are likely to get - use the code block button (PRE tags) to preserve formatting when showing multi-line code snippets
-
Hi all, I've got a strange problem while trying to save a file. Accidentally it occurs, that an existing file, which will be overwritten by my application, is still opened by photometadatahandler.dll. This happens after I close the 'save file dialog' of my application. This is what I do: - OpenFileDialog (for saving file) - Select existing file - Press ok - Try to do a CreateFile The CreateFile sometimes returns INVALID_HANDLE and GetLastError shows 5=Access denied. Now I did the following as a workaround, instead of a simple CreateFile: do { myhandle = CreateFile(...); err = GetLastError(); TRACE("CreateFile handle %x error %x", myhandle, err); if(myhandle == INVALID...) Sleep(500); // try to enable other threads... }while((myhandle == INVALID...) && (some timeout condition)) My Trace output shows this: CreateFile handle ffffffff error 5 CreateFile handle ffffffff error 5 'MyApp.exe': Unloaded 'C:\Windows\System32\PhotoMetadataHandler.dll' CreateFile handle 200 error 0 The Photo..blah.dll seems to lock my file. 1. How can I wait till the photo..blah.dll is unloaded? 2. Or how can I force to unload this dll? Any thoughts? jung-kreidler
And this is my second standard reaction, AFAIK it applies to .NET only: Image.Save() failure Most, if not all, errors inside GDI+ are reported as "generic problem occurred in GDI+". If the affected line is an Image.Save chances are your path is incorrect or inaccessible, your disk is full, or your destination file exists and is locked. if you load an image from a file, most of the time the file remains locked as long as the Image is alive. This would prevent you from saving an image to the same path. It applies to Image.FromFile, and probably also to PictureBox.ImageLocation The one exception I am aware of is when you use Image.FromStream An alternative work-around is to work with a copy of the image: load the image with Image.FromFile, create a new image from it with new Bitmap(Image), dispose of the original image. :)
Luc Pattyn [Forum Guidelines] [My Articles]
- before you ask a question here, search CodeProject, then Google - the quality and detail of your question reflects on the effectiveness of the help you are likely to get - use the code block button (PRE tags) to preserve formatting when showing multi-line code snippets
-
Hi, this is my standard first reaction to the symptoms you described, it may or may not apply to your situation: if you want write or delete access (anything other than read access) to a file that just got created (by yourself or someone else, does not matter), chances are you will find the file is being accessed by some other process, and your access is not granted. The other process very likely is some server code that is there to assist you somehow. Candidates are: - anti-virus software (Norton, McAfee, whatever) - indexing software (Google Desktop, MS Office, whatever) The common thing is these packages are looking all the time for new files, so they can inspect them. Microsoft is aware of the consequences; Windows Explorer will try rename and delete attempts up to five times (with one-second interval), and only reports failure if the action continues to fail for that time. The solution: 1. either use a different file name 2. or remove all background reader candidates (bad idea) 3. or implement the retry loop as Explorer has it (use a Windows.Forms.Timer for this) :)
Luc Pattyn [Forum Guidelines] [My Articles]
- before you ask a question here, search CodeProject, then Google - the quality and detail of your question reflects on the effectiveness of the help you are likely to get - use the code block button (PRE tags) to preserve formatting when showing multi-line code snippets
Thanks Luc. My project runs with c++ and MFC. The background reader is a microsoft module: Photometadatahandler, which seems to scan the files inside the directory in another thread, while the Save-Dialog is open. After closing the dialog this Photometadatahandler-Thread is still alive and locks my file. So, how can I get rid of this Photo...dll after the dialog is closed (the handler is useless without the dialog). For me it seems to be a MS-bug, since it is timing dependent. jung-kreidler
-
Thanks Luc. My project runs with c++ and MFC. The background reader is a microsoft module: Photometadatahandler, which seems to scan the files inside the directory in another thread, while the Save-Dialog is open. After closing the dialog this Photometadatahandler-Thread is still alive and locks my file. So, how can I get rid of this Photo...dll after the dialog is closed (the handler is useless without the dialog). For me it seems to be a MS-bug, since it is timing dependent. jung-kreidler
so it behaves like an indexing software, exactly what I mentioned earlier. Use a fivefold retry loop with one-second delay.
jung-kreidler wrote:
it seems to be a MS-bug, since it is timing dependent
Nobody but Microsoft can make time dependant bugs then? :laugh:
Luc Pattyn [Forum Guidelines] [My Articles]
- before you ask a question here, search CodeProject, then Google - the quality and detail of your question reflects on the effectiveness of the help you are likely to get - use the code block button (PRE tags) to preserve formatting when showing multi-line code snippets
-
so it behaves like an indexing software, exactly what I mentioned earlier. Use a fivefold retry loop with one-second delay.
jung-kreidler wrote:
it seems to be a MS-bug, since it is timing dependent
Nobody but Microsoft can make time dependant bugs then? :laugh:
Luc Pattyn [Forum Guidelines] [My Articles]
- before you ask a question here, search CodeProject, then Google - the quality and detail of your question reflects on the effectiveness of the help you are likely to get - use the code block button (PRE tags) to preserve formatting when showing multi-line code snippets
Yep, did so. It's somewhat ugly X| , but in case there is no other way I can live with it. :-D Thank you. jung-kreidler EDIT: I was able to catch the thread, which blocks my file. The thread tries to Free and Release allocated stuff and thus is in its shutdown sequence. After closing the dialog this thread MUST be synchronized with the dialog shutdown, which is not the case... and I have to wait, since I can't synch with this thread... Another issue came up while testing: The file is deleted after the CreateFile finally failed, which is not intended, I think. :-\ ... timing bugs, hmm, is not only a Microsoft domain :-O ... Sorry, but my english jumped the rails while being in the battle.
modified on Wednesday, February 18, 2009 10:11 AM