save as dialog and shered directory rights

  • Thread starter Thread starter Koliber (js)
  • Start date Start date
K

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
 
Koliber said:
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),
Click to expand...

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 )
Click to expand...

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?
Click to expand...

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
Click to expand...

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)
Click to expand...

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 said:
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.
Click to expand...

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
 
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.
Click to expand...

This isn't true. The SaveFileDialog calls the GetSaveFileName API
function in Windows. This API does create a file to determine if the a new
file can be created in the selected directory. From the MSDN documentation:

http://msdn2.microsoft.com/en-us/library/ms646960.aspx

Specifically, in the section titled "File and Directory Validation", it
states:
By default, the dialog box creates a zero-length test file to determine
whether a new file can be created in the selected directory. To prevent the
creation of this test file, set the OFN_NOTESTFILECREATE flag.

Looking in Reflector, the SaveFileDialog class does not set this flag
before calling GetSaveFileName.

Because of that, I would say it is more than likely that it is not a
problem with the OP's code.

Back to the OP, the SaveFileDialog class is sealed, so you can't derive
from it to try and set the flag yourself. You might have to resort to
calling the GetSaveFileName API through the P/Invoke layer, and then setting
the OFN_NOTESTFILECREATE yourself. Be careful though. From the
documentation for the OPENFILENAME structure:

Specifies that the file is not created before the dialog box is closed. This
flag should be specified if the application saves the file on a
create-nonmodify network share. When an application specifies this flag, the
library does not check for write protection, a full disk, an open drive
door, or network protection. Applications using this flag must perform file
operations carefully, because a file cannot be reopened once it is closed.

So be aware that those checks won't be performed when you set that flag.

If you want something more reusable, then you could derive from the
FileDialog class, and then override the RunDialog method to call the
GetSaveFileName API yourself.
 
Nicholas said:
This isn't true.
Click to expand...

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
 
Back
Top