save as dialog and shered directory rights

[Koliber (js)]

sorry for my bad english

when I fire up (from my c# code) a standard "file - save as "
dialog, and when chosen location is a shered local network
directory, where I do have rights to create and modify files,
but I do not have rights to delete one,

(and do save as with my filename)

then this standard windows dialog seem to create empty
file (size 0 bytes), with my filename (IT IS WEIRD), and then
try to delete it - and because of absence of rights to delete
fails the whole simple operation (there is a box
with message cannot delete file )

My question is - what is about that? and the second
and more important - where in dotnetframework
I will find a method which let me to test which rights
(to file operations in selected directory) I do have
(so I cauld check it before I try to call this
save as file dialog wchih in other case fail
operations I try to do (I mean save file)
(or yet better how to avoid this windows bug and
save my file in such directory)
T I A

kenobi

[Peter Duniho]

Koliber (js) wrote:

sorry for my bad english

when I fire up (from my c# code) a standard "file - save as "
dialog, and when chosen location is a shered local network
directory, where I do have rights to create and modify files,
but I do not have rights to delete one,

(and do save as with my filename)

then this standard windows dialog seem to create empty
file (size 0 bytes),

The SaveFileDialog does not create a file. It only returns a filename,
for a file that may or may not exist. So if a file is being created,
it's your own code doing it.

with my filename (IT IS WEIRD), and then

try to delete it - and because of absence of rights to delete
fails the whole simple operation (there is a box
with message cannot delete file )

Well, if you have sufficient privileges to create a file but not to
delete files, then yes...you may wind up creating a file that you can't
delete.

Why the file is 0 length, I can't say. If you actually have the
appropriate rights to create and then append to files in that directory,
you should be able to write new data to the file. There is probably
something else you're doing wrong that you haven't explained yet.

My question is - what is about that?

What is about what?

and the second

and more important - where in dotnetframework
I will find a method which let me to test which rights
(to file operations in selected directory) I do have

You should look at the stuff supporting "access control lists", or ACL.

(so I cauld check it before I try to call this
save as file dialog wchih in other case fail
operations I try to do (I mean save file)
(or yet better how to avoid this windows bug and
save my file in such directory)

Why do you say this is a Windows bug? Windows is doing exactly what you
tell it to. If you don't like it doing that, then don't tell it to do that.

If the above does not give you enough information to fix your code, you
should post a concise-but-complete sample of code that reliably
reproduces the problem (given an appropriately-configured directory on
the disk, of course...I realize you can't post the directory, but it
should be easy enough to replicate, if you provide exact details of the
security settings on the directory for the user in question).

Pete

[Peter Duniho]

Peter Duniho wrote:

Why the file is 0 length, I can't say. If you actually have the
appropriate rights to create and then append to files in that directory,
you should be able to write new data to the file. There is probably
something else you're doing wrong that you haven't explained yet.

And just to clarify: in Windows, the right to create a file or modify it
is not the same as the right to append to a file. So since your file is
only 0 length, I suspect that you don't actually have the "append data"
right to the directory (and thus new files created in the directory).

You should be getting an exception if your file writing fails though.
If you look at the exception, it should give you some clues as to what's
actually going on.

Pete

[Peter Duniho]

Nicholas Paldino [.NET/C# MVP] wrote:

>The SaveFileDialog does not create a file. It only returns a filename,
for a file that may or may not exist. So if a file is being created, it's
your own code doing it.

This isn't true.

See...I told you I wasn't always 100% correct.

Note, however, that the behavior the OP is seeing is strictly due to the
permissions set on the directory. Normally, the test file is deleted
before the dialog returns control to the calling code. For all intents
and purposes, it doesn't create a file, as far as the calling code is
normally concerned.

But because the OP doesn't have rights to delete the file, the test file
remains.

In any case, presumably the OP would have created the file anyway, and
presumably the OP would have tried to write to the file anyway, so I
still say the only way for what they are describing to happen is for
them to not have append and delete rights to the directory in which they
are trying to create the file.

Still not a Windows bug, and still addressable in exactly the way I
described (ie check the access control list for the directory first).
Even if they disable the "test file" behavior in SaveFileDialog, they
will run into the same problem once they actually try to do something
with the filename (that is, try to write to the file).

If the OP does not intend to try to create a file, then the
SaveFileDialog isn't appropriate and I would recommend not using it.

Pete