Re: SaveFileDialog locks the file?
"Willy Denoyette [MVP]" <willy.denoyett e@telenet.bewro te in message
news:%23ByyBu%2 31GHA.1548@TK2M SFTNGP02.phx.gb l...
And you are talking like a Microsoft apologist, one who can't imagine that
an API ought to have a consistent, deterministic, reliable behavior.
It's one thing for there to be a possibility that the file might become
locked before I try to access it. Any number of processes may do that, and
that's fine with me. However, it's just plain *dumb* for the one API that
is supposed to return a file to open for writing to actually *lock* that
file and not unlock it before returning that file information to the program
that called it.
Do you actually believe that it is reasonable behavior to require the caller
to loop, repeatedly attempting to open the desired file until it can be
opened?
As I said before, all I'm doing is creating a new FileStream, using the "new
FileStream()" syntax. It's not rocket science.
Do you mean "OpenFile"? There's no "FileOpen" method.
Where in the documentation does it say that "it's up to me to implement the
file creation and Save logics"? In the documentation for
SaveFileDialog. OpenFile, it reads:
"Opens the file with read/write permission selected by the user"
Furthermore, it *specifically* says to use the FileName property to avoid
having the SaveFileDialog from deleting existing data in an existing file:
"For security purposes, this method creates a new file with the selected
name and opens it with read/write permissions. This can cause unintentional
loss of data if you select an existing file to save to. To save data to an
existing file while retaining existing data, use the File class to open the
file using the file name returned in the FileName property"
I see absolutely no documentation that says "if the file exists, OpenFile
returns a null stream reference". In fact, it specifically says that if the
file exists, it will still return a valid stream, but will overwrite the
existing file with a new one. Nor do I see anything that says that it's up
to me "to implement the file creation and Save logics" (unless by that you
simply mean that I need to use the FileName property as a parameter to a
method such as creating a new FileStream object, in which case *that's
exactly what I'm doing*).
Nowhere in the documentation does it suggest that the SaveFileDialog may
itself lock the file and that I need to repeatedly attempt to open the file
until it has unlocked it.
You have several times referred to documentation that does not appear to
actually exist. Perhaps you could actually post some references in the form
of URLs where I can read the supposed documentation that says I'm doing this
all wrong.
I have NEVER seen this happen, and I was one of the very first developers to
actually use the common file dialogs. It's true, a lot of years have gone
by since they first appeared, and who knows what people at Microsoft have
done since then. But I've never seen the file save dialog keep a file
locked after returning to the caller, except in the .NET context.
That strongly suggests a possible .NET relevance.
If you can post a non-.NET example that reproduces the exact same problem, I
will be happy to accept your claim that this is not a .NET problem. Until
then the evidence, however circumstantial it may be, points to a .NET
problem.
From the documentation:
"Prompts the user to select a location for saving a file. This class cannot
be inherited"
and
"This class can either open and overwrite an existing file or create a new
file. Most of the functionality for this class is found in the FileDialog
class"
That's it as far as "explained in the docs what the class is designed for".
There's no mention in the FileDialog class description about the dialog
locking the file, or suggesting that I am improperly using the class by
getting the file name from the FileName property.
Where in the documentation do you see it saying that I should not get the
file name from the FileName property, or that I must call the OpenFile
method, or that the OpenFile method returns a null stream if the file
exists, or that if a null stream is returned, I must implement my own file
open and save logic?
It doesn't matter if the side effects may be different if the SaveFileDialog
class is the correct class to use. You specifically asked me why I'm not
using the OpenFileDialog, as if that was the class I was supposed to use.
Since it's NOT the class I'm supposed to use, how it behaves isn't relevant
here, not with respect to solving the problem being discussed.
Pete
"Willy Denoyette [MVP]" <willy.denoyett e@telenet.bewro te in message
news:%23ByyBu%2 31GHA.1548@TK2M SFTNGP02.phx.gb l...
You are talking like a naive developer, the one who doesn't look any
further
than the small API set he's using. if something goes wrong it's the API.
further
than the small API set he's using. if something goes wrong it's the API.
an API ought to have a consistent, deterministic, reliable behavior.
It's one thing for there to be a possibility that the file might become
locked before I try to access it. Any number of processes may do that, and
that's fine with me. However, it's just plain *dumb* for the one API that
is supposed to return a file to open for writing to actually *lock* that
file and not unlock it before returning that file information to the program
that called it.
Do you actually believe that it is reasonable behavior to require the caller
to loop, repeatedly attempting to open the desired file until it can be
opened?
| Do I refrain from saying that my program locks the file when it wants to
| write to it, just because it's not actually my code that does the actual
| locking? I don't think so.
|
>
I can't tell, you don't post that significant part of your code, I don't
know what you are doing in,
>
if (szFile != null)
{
// open file here...this is where the exception occurs
}
I have no idea how you do open the file, all I know is that there is a
sharing conflict. So please post your implementation, investigate who's
holding the file and in what mode it's been opened, else I will stop
replying.
| write to it, just because it's not actually my code that does the actual
| locking? I don't think so.
|
>
I can't tell, you don't post that significant part of your code, I don't
know what you are doing in,
>
if (szFile != null)
{
// open file here...this is where the exception occurs
}
I have no idea how you do open the file, all I know is that there is a
sharing conflict. So please post your implementation, investigate who's
holding the file and in what mode it's been opened, else I will stop
replying.
FileStream()" syntax. It's not rocket science.
[...]
No, sorry, this is realy badly explained. Here's another try:
If the file doesn't exists, FileOpen creates the file with RW access and
returns the stream reference, as the file doesn't exists, it cannot be
opened by someone else, no problem here.
However, if the file exists, FileOpen returns a null stream reference, and
it's up to you to implement the file creation and Save logics. [...]
No, sorry, this is realy badly explained. Here's another try:
If the file doesn't exists, FileOpen creates the file with RW access and
returns the stream reference, as the file doesn't exists, it cannot be
opened by someone else, no problem here.
However, if the file exists, FileOpen returns a null stream reference, and
it's up to you to implement the file creation and Save logics. [...]
Where in the documentation does it say that "it's up to me to implement the
file creation and Save logics"? In the documentation for
SaveFileDialog. OpenFile, it reads:
"Opens the file with read/write permission selected by the user"
Furthermore, it *specifically* says to use the FileName property to avoid
having the SaveFileDialog from deleting existing data in an existing file:
"For security purposes, this method creates a new file with the selected
name and opens it with read/write permissions. This can cause unintentional
loss of data if you select an existing file to save to. To save data to an
existing file while retaining existing data, use the File class to open the
file using the file name returned in the FileName property"
I see absolutely no documentation that says "if the file exists, OpenFile
returns a null stream reference". In fact, it specifically says that if the
file exists, it will still return a valid stream, but will overwrite the
existing file with a new one. Nor do I see anything that says that it's up
to me "to implement the file creation and Save logics" (unless by that you
simply mean that I need to use the FileName property as a parameter to a
method such as creating a new FileStream object, in which case *that's
exactly what I'm doing*).
Nowhere in the documentation does it suggest that the SaveFileDialog may
itself lock the file and that I need to repeatedly attempt to open the file
until it has unlocked it.
You have several times referred to documentation that does not appear to
actually exist. Perhaps you could actually post some references in the form
of URLs where I can read the supposed documentation that says I'm doing this
all wrong.
It has nothing to do with .NET. But of course to you, everything is .NET
once you use the framework, right?
once you use the framework, right?
actually use the common file dialogs. It's true, a lot of years have gone
by since they first appeared, and who knows what people at Microsoft have
done since then. But I've never seen the file save dialog keep a file
locked after returning to the caller, except in the .NET context.
That strongly suggests a possible .NET relevance.
If you can post a non-.NET example that reproduces the exact same problem, I
will be happy to accept your claim that this is not a .NET problem. Until
then the evidence, however circumstantial it may be, points to a .NET
problem.
[...]
No, they don't, it's explained in the docs what the class is designed for,
if you don't like the behavior, you will have to design your own save
dialog.
No, they don't, it's explained in the docs what the class is designed for,
if you don't like the behavior, you will have to design your own save
dialog.
"Prompts the user to select a location for saving a file. This class cannot
be inherited"
and
"This class can either open and overwrite an existing file or create a new
file. Most of the functionality for this class is found in the FileDialog
class"
That's it as far as "explained in the docs what the class is designed for".
There's no mention in the FileDialog class description about the dialog
locking the file, or suggesting that I am improperly using the class by
getting the file name from the FileName property.
Where in the documentation do you see it saying that I should not get the
file name from the FileName property, or that I must call the OpenFile
method, or that the OpenFile method returns a null stream if the file
exists, or that if a null stream is returned, I must implement my own file
open and save logic?
[...]
| Then why are you questioning my use of the SaveFileDialog versus the
| OpenFileDialog? How is my use of the SaveFileDialog rather than the
| OpenFileDialog relevant to this question at all?
>
The side effects may be different as the explorer hook procedures may be
different.
| OpenFileDialog? How is my use of the SaveFileDialog rather than the
| OpenFileDialog relevant to this question at all?
>
The side effects may be different as the explorer hook procedures may be
different.
It doesn't matter if the side effects may be different if the SaveFileDialog
class is the correct class to use. You specifically asked me why I'm not
using the OpenFileDialog, as if that was the class I was supposed to use.
Since it's NOT the class I'm supposed to use, how it behaves isn't relevant
here, not with respect to solving the problem being discussed.
Pete
Comment