SaveFileDialog locks the file?

[Peter Duniho]

I searched using Google, on the web and in the newsgroups, and found nothing
on this topic. Hopefully that means I just don't understand what I'm
supposed to be doing here. :)

The problem:

I am trying to use the SaveFileDialog class to get a filename, which is
subsequently opened for writing (write access, read sharing, but using
read/write sharing doesn't make the problem go away anyway). Sometimes, on
the statement where I actually open the file (using the FileName string from
the SaveFileDialog instance) I get an IOException complaining that the file
is in use by another process (says it can't open "...because it is being
used by another process").

Because this error occurs more often the more quickly I click through the
UI, it suggested strongly that there was some uncollected resource somewhere
causing problems. However, I have been unable to fix the problem using the
mechanisms I know of for addressing those issues ("using" or calling
GC.Collect(), for example).

I have narrowed the problem down to the SaveFileDialog itself. That is, if
I instead hard-code the filename as a string and repeatedly run the save
command, I never get the error, no matter how quickly I resave the file over
and over. If, however, I include the SaveFileDialog, the error occurs quite
often, sometimes even on the very first access of the file during a given
program execution.

Not that I think this sort of thing should be necessary, but I've tried two
different possible work-arounds, neither of which fixed the problem:

string szFile = null;

using (SaveFileDialog sfd = new SaveFileDialog( ))
{
if (sfd.ShowDialog (this) == DialogResult.OK )
{
szFile = sfd.FileName;
}
}

if (szFile != null)
{
// open file here...this is where the exception occurs
}

And, alternatively:

SaveFileDialog sfd = new SaveFileDialog( );

if (sfd.ShowDialog (this) == DialogResult.OK )
{
string szFile = sfd.FileName;

sfd = null;
GC.Collect();

// open file here...this is where the exception occurs
}

So, any ideas? Has anyone seen this before? As I mentioned, if I don't use
the SaveFileDialog and instead just set the filename variable directly in
code, the problem completely disappears. It seems obvious to me that the
SaveFileDialog is somehow keeping the file open, but I don't understand why,
nor do I understand how I can get it to release the file so that I can open
it myself.

Much thanks,
Pete

[Ben Voigt]

"Peter Duniho" <Np*********@Nn OwSlPiAnMk.comw rote in message
news:12******** ****@corp.super news.com...

>I searched using Google, on the web and in the newsgroups, and found
nothing on this topic. Hopefully that means I just don't understand what
I'm supposed to be doing here. :)

The problem:

I am trying to use the SaveFileDialog class to get a filename, which is
subsequently opened for writing (write access, read sharing, but using
read/write sharing doesn't make the problem go away anyway). Sometimes,
on the statement where I actually open the file (using the FileName string
from the SaveFileDialog instance) I get an IOException complaining that
the file is in use by another process (says it can't open "...because it
is being used by another process").

Tried using SaveFileDialog. OpenFile instead of the FileName property?

[Peter Duniho]

"Ben Voigt" <rb*@nospam.nos pamwrote in message
news:e4******** ******@TK2MSFTN GP02.phx.gbl...

Tried using SaveFileDialog. OpenFile instead of the FileName property?

I may look at that just to see whether it also has the problem, so I can
provide a more complete bug report. But the OpenFile method doesn't provide
any parameters for specifying file access, buffer size, etc. and so is
unsuitable in my particular situation (ie, the default open behavior isn't
sufficient). Even if it makes the problem go away, it's not a solution for
this particular case. :(

Thanks,
Pete

[Emby]

Hi Pete,

Sorry, I don't have a solution, but I will confirm that I've seen this
behavior. I've not correlated it to the SF dialog; it has always seemed
infrequent and inconsistent. I just figured it was yet another of VS8's many
little bugs ... :(
... so where is that SP1??

I'll try "clicking faster" and see what happens.

Emby

"Peter Duniho" <Np*********@Nn OwSlPiAnMk.comw rote in message
news:12******** ****@corp.super news.com...

>I searched using Google, on the web and in the newsgroups, and found
nothing on this topic. Hopefully that means I just don't understand what
I'm supposed to be doing here. :)

The problem:

I am trying to use the SaveFileDialog class to get a filename, which is
subsequently opened for writing (write access, read sharing, but using
read/write sharing doesn't make the problem go away anyway). Sometimes,
on the statement where I actually open the file (using the FileName string
from the SaveFileDialog instance) I get an IOException complaining that
the file is in use by another process (says it can't open "...because it
is being used by another process").

Because this error occurs more often the more quickly I click through the
UI, it suggested strongly that there was some uncollected resource
somewhere causing problems. However, I have been unable to fix the
problem using the mechanisms I know of for addressing those issues
("using" or calling GC.Collect(), for example).

I have narrowed the problem down to the SaveFileDialog itself. That is,
if I instead hard-code the filename as a string and repeatedly run the
save command, I never get the error, no matter how quickly I resave the
file over and over. If, however, I include the SaveFileDialog, the error
occurs quite often, sometimes even on the very first access of the file
during a given program execution.

Not that I think this sort of thing should be necessary, but I've tried
two different possible work-arounds, neither of which fixed the problem:

string szFile = null;

using (SaveFileDialog sfd = new SaveFileDialog( ))
{
if (sfd.ShowDialog (this) == DialogResult.OK )
{
szFile = sfd.FileName;
}
}

if (szFile != null)
{
// open file here...this is where the exception occurs
}

And, alternatively:

SaveFileDialog sfd = new SaveFileDialog( );

if (sfd.ShowDialog (this) == DialogResult.OK )
{
string szFile = sfd.FileName;

sfd = null;
GC.Collect();

// open file here...this is where the exception occurs
}

So, any ideas? Has anyone seen this before? As I mentioned, if I don't
use the SaveFileDialog and instead just set the filename variable directly
in code, the problem completely disappears. It seems obvious to me that
the SaveFileDialog is somehow keeping the file open, but I don't
understand why, nor do I understand how I can get it to release the file
so that I can open it myself.

Much thanks,
Pete

[Peter Duniho]

"Emby" <em**@blaisesof t-xxx.comwrote in message
news:uj******** ******@TK2MSFTN GP04.phx.gbl...

Hi Pete,

Sorry, I don't have a solution, but I will confirm that I've seen this
behavior. I've not correlated it to the SF dialog; it has always seemed
infrequent and inconsistent. I just figured it was yet another of VS8's
many little bugs ... :(
... so where is that SP1??

I'll try "clicking faster" and see what happens.

Well, I'm glad to hear I'm not entirely insane. :)

I have been doing a little more investigation. I don't think I've come up
with too much in the way of insight, but here's what new I've learned about
the issue:

* A suitable workaround appears to be to wrap a try/catch in a loop with
a counter, and to repeatedly attempt to open the file. I call
Thread.Sleep(10 00) for each failure, and only try five times. Doing this,
about half the time it would take two tries to open the file, but never more
than that. It's ugly, but it does work.

* Another suitable workaround appears to be to write to a temp file
first, and then move the file over. This is a common enough technique
generally and one I was implementing for other reasons anyway, and it
appears to allow for enough time for the file to become unlocked before you
have to delete it (so that the rename/move can happen). Note: this doesn't
really avoid the problem per se...it just shifts things around enough that
it becomes a lot more rare (ie, this isn't a suitable workaround for those
"must work absolutely 100% of the time" situations).

On that second item, I will also note that I was in fact still able to
reproduce a problem once. However, it occurred in an even more bizarre way:
I got an "Access Denied" exception, but the target file (which I was
overwriting) got deleted anyway, and the File.Move failed. For all I know,
this was an entirely different race condition bug, in which the delete did
occur but the OS didn't finish it in time for the File.Move call to succeed.

I'm not doing any async i/o, so there *shouldn't* be any race conditions at
all. But it does appear that even though I'm doing everything sequentially
and synchronously, there is other stuff going on behind my back (maybe
within .NET, and maybe just in Windows...I can't tell the difference with
the information I have).

Finally, one interesting tidbit:

* The file that I'm working with for testing is a DivX AVI file. I've
noticed that every time I run the SaveFileDialog, the little DivX notify
icon shows up. I suspect this happens as the SaveFileDialog (or more
likely, the built-in Windows common file dialog...it'd be kind of silly for
..NET to completely reinvent that wheel rather than just calling Windows to
do it) generates thumbnails to present in the dialog. I have a suspicion
that this is somehow related to whatever is causing the file to be locked.

Of course, it is .NET that is calling the common dialog, and it is the
common dialog that is running the multimedia code that calls DivX to
generate a thumbnail. I have no doubt that a lot of finger-pointing may be
in the offing when it comes to trying to actually *fix* the problem. But
hopefully, the various teams involved can coordinate and come up with a
solution.

Thanks for your input,
Pete

[Willy Denoyette [MVP]]

"Peter Duniho" <Np*********@Nn OwSlPiAnMk.comw rote in message
news:12******** ****@corp.super news.com...
|I searched using Google, on the web and in the newsgroups, and found
nothing
| on this topic. Hopefully that means I just don't understand what I'm
| supposed to be doing here. :)
|
| The problem:
|
| I am trying to use the SaveFileDialog class to get a filename, which is
| subsequently opened for writing (write access, read sharing, but using
| read/write sharing doesn't make the problem go away anyway). Sometimes,
on
| the statement where I actually open the file (using the FileName string
from
| the SaveFileDialog instance) I get an IOException complaining that the
file
| is in use by another process (says it can't open "...because it is being
| used by another process").
|
| Because this error occurs more often the more quickly I click through the
| UI, it suggested strongly that there was some uncollected resource
somewhere
| causing problems. However, I have been unable to fix the problem using
the
| mechanisms I know of for addressing those issues ("using" or calling
| GC.Collect(), for example).
|
| I have narrowed the problem down to the SaveFileDialog itself. That is,
if
| I instead hard-code the filename as a string and repeatedly run the save
| command, I never get the error, no matter how quickly I resave the file
over
| and over. If, however, I include the SaveFileDialog, the error occurs
quite
| often, sometimes even on the very first access of the file during a given
| program execution.
|
| Not that I think this sort of thing should be necessary, but I've tried
two
| different possible work-arounds, neither of which fixed the problem:
|
| string szFile = null;
|
| using (SaveFileDialog sfd = new SaveFileDialog( ))
| {
| if (sfd.ShowDialog (this) == DialogResult.OK )
| {
| szFile = sfd.FileName;
| }
| }
|
| if (szFile != null)
| {
| // open file here...this is where the exception occurs
| }
|
| And, alternatively:
|
| SaveFileDialog sfd = new SaveFileDialog( );
|
| if (sfd.ShowDialog (this) == DialogResult.OK )
| {
| string szFile = sfd.FileName;
|
| sfd = null;
| GC.Collect();
|
| // open file here...this is where the exception occurs
| }
|
| So, any ideas? Has anyone seen this before? As I mentioned, if I don't
use
| the SaveFileDialog and instead just set the filename variable directly in
| code, the problem completely disappears. It seems obvious to me that the
| SaveFileDialog is somehow keeping the file open, but I don't understand
why,
| nor do I understand how I can get it to release the file so that I can
open
| it myself.
|
| Much thanks,
| Pete
|

The SaveFileDialog does not open the selected file unless you open the file
by calling SaveFileDialog. OpenFile. Note that I don't quite understand why
you are using SaveFileDialog instead of the OpenFileDialog, you aren't using
any functionality of this class other than select a file.

What version of the framework are you running?
Willy.

[Emby]

Hi Willy,

I am using framework v2 (I think Pete is as well).

I won't speak for Pete, but I'm using the File Save Dialog because, well,
the user is specifying a file to which they are saving data. This has a
somewhat different action than the Open file dialog. For example, Open has
props like "ShowReadOn ly" and "MultiSelec t", while Save has "CreateProm pt"
and "OverwritePromp t".

Both of the dialogs select files, but the FS dialog selects a file to write
to, while the OF dialog selects a file to read from.

Emby

"Willy Denoyette [MVP]" <wi************ *@telenet.bewro te in message
news:u6******** ******@TK2MSFTN GP04.phx.gbl...

>
"Peter Duniho" <Np*********@Nn OwSlPiAnMk.comw rote in message
news:12******** ****@corp.super news.com...
|I searched using Google, on the web and in the newsgroups, and found
nothing
| on this topic. Hopefully that means I just don't understand what I'm
| supposed to be doing here. :)
|
| The problem:
|
| I am trying to use the SaveFileDialog class to get a filename, which is
| subsequently opened for writing (write access, read sharing, but using
| read/write sharing doesn't make the problem go away anyway). Sometimes,
on
| the statement where I actually open the file (using the FileName string
from
| the SaveFileDialog instance) I get an IOException complaining that the
file
| is in use by another process (says it can't open "...because it is being
| used by another process").
|
| Because this error occurs more often the more quickly I click through
the
| UI, it suggested strongly that there was some uncollected resource
somewhere
| causing problems. However, I have been unable to fix the problem using
the
| mechanisms I know of for addressing those issues ("using" or calling
| GC.Collect(), for example).
|
| I have narrowed the problem down to the SaveFileDialog itself. That is,
if
| I instead hard-code the filename as a string and repeatedly run the save
| command, I never get the error, no matter how quickly I resave the file
over
| and over. If, however, I include the SaveFileDialog, the error occurs
quite
| often, sometimes even on the very first access of the file during a
given
| program execution.
|
| Not that I think this sort of thing should be necessary, but I've tried
two
| different possible work-arounds, neither of which fixed the problem:
|
| string szFile = null;
|
| using (SaveFileDialog sfd = new SaveFileDialog( ))
| {
| if (sfd.ShowDialog (this) == DialogResult.OK )
| {
| szFile = sfd.FileName;
| }
| }
|
| if (szFile != null)
| {
| // open file here...this is where the exception occurs
| }
|
| And, alternatively:
|
| SaveFileDialog sfd = new SaveFileDialog( );
|
| if (sfd.ShowDialog (this) == DialogResult.OK )
| {
| string szFile = sfd.FileName;
|
| sfd = null;
| GC.Collect();
|
| // open file here...this is where the exception occurs
| }
|
| So, any ideas? Has anyone seen this before? As I mentioned, if I don't
use
| the SaveFileDialog and instead just set the filename variable directly
in
| code, the problem completely disappears. It seems obvious to me that
the
| SaveFileDialog is somehow keeping the file open, but I don't understand
why,
| nor do I understand how I can get it to release the file so that I can
open
| it myself.
|
| Much thanks,
| Pete
|

The SaveFileDialog does not open the selected file unless you open the
file
by calling SaveFileDialog. OpenFile. Note that I don't quite understand why
you are using SaveFileDialog instead of the OpenFileDialog, you aren't
using
any functionality of this class other than select a file.

What version of the framework are you running?
Willy.

[Peter Duniho]

"Willy Denoyette [MVP]" <wi************ *@telenet.bewro te in message
news:u6******** ******@TK2MSFTN GP04.phx.gbl...

The SaveFileDialog does not open the selected file unless you open the
file
by calling SaveFileDialog. OpenFile.

It obviously does so. Whether it's the .NET portion of SaveFileDialog
that's doing that or not, I can't say. For all I know, this is a general
problem that exists in the regular Win32 common dialog implementations ,
inhereted by .NET. But invoking the dialog results in the file being
locked, that much I am sure.

Note that I don't quite understand why
you are using SaveFileDialog instead of the OpenFileDialog, you aren't
using
any functionality of this class other than select a file.

Um, because I am prompting the user to *save* the file. It is simply not
true that I am not "using any functionality of this class other than select
a file". There are genuine and subtle differences between the way the Open
and Save dialogs work, and it's important for an application to use the
appropriate one in the appropriate situation to preserve these subtle
differences.

Is it your assertion that it's my fault the problem I am having because I'm
using the SaveFileDialog instead of the OpenFileDialog? If not, I'm at a
loss as to why you would even mention it anyway (even assuming it was a
legitimate complaint of my code, when it's obviously not).

What version of the framework are you running?

..NET 2.0.

Pete

[Willy Denoyette [MVP]]

"Emby" <em**@blaisesof t-xxx.comwrote in message
news:eV******** ******@TK2MSFTN GP02.phx.gbl...
| Hi Willy,
|
| I am using framework v2 (I think Pete is as well).
|
| I won't speak for Pete, but I'm using the File Save Dialog because, well,
| the user is specifying a file to which they are saving data. This has a
| somewhat different action than the Open file dialog. For example, Open has
| props like "ShowReadOn ly" and "MultiSelec t", while Save has "CreateProm pt"
| and "OverwritePromp t".
|
| Both of the dialogs select files, but the FS dialog selects a file to
write
| to, while the OF dialog selects a file to read from.
|

Right, but you should know that the way you use this common control, you
opened a can of worms. The FileDialog is wrapping a native common control
(as you rightfully concluded yourself), which integrates with the shell
(explorer.exe), When selecting a file and accepting the selection (OK
DialogResult), explorer will be notified to query the file properties and
perform some housekeeping like updating the recent used documents list, for
this the explorer process needs to open the file (unfortunately non shared),
if you look at your code, this will mostly occur at the same time you try to
open the file for writing, which obvioulsly fails.
One thing you can try is to insert a Thread.Sleep(10 0); after the using
block, this should give sufficient time to explorer to execute it's task and
to close the file.

Willy.

[Willy Denoyette [MVP]]

"Peter Duniho" <Np*********@Nn OwSlPiAnMk.comw rote in message
news:12******** *****@corp.supe rnews.com...
| "Willy Denoyette [MVP]" <wi************ *@telenet.bewro te in message
| news:u6******** ******@TK2MSFTN GP04.phx.gbl...
| The SaveFileDialog does not open the selected file unless you open the
| file
| by calling SaveFileDialog. OpenFile.
|
| It obviously does so. Whether it's the .NET portion of SaveFileDialog
| that's doing that or not, I can't say. For all I know, this is a general
| problem that exists in the regular Win32 common dialog implementations ,
| inhereted by .NET. But invoking the dialog results in the file being
| locked, that much I am sure.
|
No it's not the SaveFileDialog which locks the file (it doesn't even open
the file), it's the explorer.exe (the windwos shell) who opens the file.

| Note that I don't quite understand why
| you are using SaveFileDialog instead of the OpenFileDialog, you aren't
| using
| any functionality of this class other than select a file.
|
| Um, because I am prompting the user to *save* the file. It is simply not
| true that I am not "using any functionality of this class other than
select
| a file". There are genuine and subtle differences between the way the
Open
| and Save dialogs work, and it's important for an application to use the
| appropriate one in the appropriate situation to preserve these subtle
| differences.
|

This class is a simple solution for users to save file data using standard
Windows dialogs, you have to implement your own save logic, to do so you
should use the OpenFile method (which keeps a copy of the original file) and
attach it to a stream, which you can change or not and finaly save. Now ,you
don't use any of this, you don't use the class as it was intended to be
used.
| Is it your assertion that it's my fault the problem I am having because
I'm
| using the SaveFileDialog instead of the OpenFileDialog? If not, I'm at a
| loss as to why you would even mention it anyway (even assuming it was a
| legitimate complaint of my code, when it's obviously not).
|

No, it's not my assertion, both OpenFileDialog and SaveFileDialog may
introduce some (maybe different) side effects because both use a Common
Control which integrates with the shell (explorer.exe) by mean of an
explorer hook procedure, this is done to display the explorer-style dialog.
Also, a shell extention component can register a handler component (COM
shell extention) to perform specific actions based on file types, the
explorer will post an event to all registerd handlers whenever a registerd
filetype is opened, the handler is free to open the file. To find the link
between the file and the handler, explorer may have to read (that is, open,
read extended file information, read volume info, close) the file and that's
exactly what happens here when the user clicks 'Save'.
Note that in general there is no problem with this, explorer closes the file
before the Dialog result is returned to the caller, but a handler may well
customize the dialog by providing a hook procedure a template or both, and
here the handler could open the file in exclusive mode and you start a race.
I would suggest you to grab a copy of Sysinternals
http://www.sysinternals.com/ "filemon" and look who's having the file open
while your program tries to open the same file.

Willy.