Does the user actually have permission to restore the item to the root of c:\?

I tested on my Win8 machine, and the user is prompted with a UAC prompt. Maybe 
the inability to restore the file might dictate whether the file goes into the 
recycle bin or not?

Cheers
Ken

From: [email protected] [mailto:[email protected]] On 
Behalf Of Ian Thomas
Sent: Friday, 18 October 2013 3:20 PM
To: 'ozDotNet'
Subject: RE: Problem with FileSystem.DeleteFile method in root directory

Greg
SHFileOperation has a lot of detail (I had a brief look yesterday, your link). 
I was looking for a pure .NET method, rather than interop - but will go with 
what is needed of course.
There is a CodeProject 
tip<http://www.codeproject.com/Tips/462878/How-to-Delete-a-File-or-Folder-to-Recyclebin>
 that may be helpful, though at the end of it he gives esentially the same code 
(using the Microsoft.VisualBasic namespace) that I had in my original post!

Comments to that article put a lot of doubt in my mind - the MSDN documentation 
on the FOF_ALLOWUNDO constant in particular.

Code straight from that article -

[StructLayout(LayoutKind.Sequential, CharSet = CharSet.Auto, Pack = 1)]
public struct SHFILEOPSTRUCT
{
    public IntPtr hwnd;
    [MarshalAs(UnmanagedType.U4)]
    public int wFunc;
    public string pFrom;
    public string pTo;
    public short fFlags;
    [MarshalAs(UnmanagedType.Bool)]
    public bool fAnyOperationsAborted;
    public IntPtr hNameMappings;
    public string lpszProgressTitle;
}

[DllImport("shell32.dll", CharSet = CharSet.Auto)]
public static extern int SHFileOperation(ref SHFILEOPSTRUCT FileOp);

public const int FO_DELETE = 3;
public const int FOF_ALLOWUNDO = 0x40;
public const int FOF_NOCONFIRMATION = 0x10;

Then

var shf = new SHFILEOPSTRUCT();
shf.wFunc = FO_DELETE;                       //Delete the files specified in 
pFrom.
shf.fFlags = FOF_ALLOWUNDO;                  //Preserve undo information, if 
possible.
shf.pFrom = @"c:\myfile.txt" + '\0' + '\0';  //File / Folder to delete
SHFileOperation(ref shf);

Doesn't work for me (deletes file after permssion granted; file not seen in 
Recycle bin) - so, no furher progressed.
________________________________
Ian Thomas
Victoria Park, Western Australia

From: [email protected]<mailto:[email protected]> 
[mailto:[email protected]] On Behalf Of Greg Keogh
Sent: Friday, October 18, 2013 7:51 AM
To: ozDotNet
Subject: Re: Problem with FileSystem.DeleteFile method in root directory

Ian, I saw some people interop calling the SHFileOperation function with a 
SHFILEOPTSTRUCT argument. They weren't doing what you are, but this function 
seems to give you total control over what happens. Maybe the fine print on the 
function and struct and all the weird flag bits might explain the behaviour 
you're seeing -- Greg

On 18 October 2013 10:14, Ian Thomas 
<[email protected]<mailto:[email protected]>> wrote:
David
Re FileIOPermissions - yes, I quickly realised that it is not relevant.
On FileSystem.DeleteFile, I think the appearance of the documentation for 
different .NET versions led me to think there was change. I don't see 
difference in behaviour for 3.5/4.0/4.5.
All of the above is not really helpful to me - it doesn't allow me to progress 
(well, it does mean that I don't go off on a tangent).
But I am still unable to remedy my problem. Do you have an answer, and 
explanation?
________________________________
Ian Thomas
Victoria Park, Western Australia
From: [email protected]<mailto:[email protected]> 
[mailto:[email protected]<mailto:[email protected]>] On 
Behalf Of David Kean
Sent: Friday, October 18, 2013 3:06 AM
To: ozDotNet
Subject: RE: Problem with FileSystem.DeleteFile method in root directory

FileIOPermission has nothing to do with the problem you are hitting; it refers 
to CAS-permissions which is a .NET only concept, and is used in partial trust 
environments such as Hosted ASP.NET<http://ASP.NET>.

There have been zero changes in this area for .NET 4.5, are you saying you are 
seeing a behavior change? These APIs delegate onto the underlying shell 
implementation; so most the behavior here would be inherited from the OS itself.

From: [email protected]<mailto:[email protected]> 
[mailto:[email protected]] On Behalf Of Ian Thomas
Sent: Thursday, October 17, 2013 5:31 AM
To: 'ozDotNet'
Subject: RE: Problem with FileSystem.DeleteFile method in root directory

Greg
I will read your link, but just now I saw at the base of the FileSystem.Delete 
info, a link to the FileIOPermission Class. First, I need to unravel the 
digfferences between .NET 4.5 and all the earlier releases; I can see major 
changes.

________________________________
Ian Thomas
Victoria Park, Western Australia
From: [email protected]<mailto:[email protected]> 
[mailto:[email protected]] On Behalf Of Greg Keogh
Sent: Thursday, October 17, 2013 8:25 PM
To: ozDotNet
Subject: Re: Problem with FileSystem.DeleteFile method in root directory

Ian, years ago I remember seeing a Q&A about how to NOT send things into the 
recycle bin, and I vaguely recall it required a Win32 API call probably in 
shell32. If you can find that call and reverse the flag it might do what you 
want.

Wait, it might be 
http://msdn.microsoft.com/en-us/library/windows/desktop/bb762164(v=vs.85).aspx, 
but I'm not certain.

Greg

On 17 October 2013 20:16, Ian Thomas 
<[email protected]<mailto:[email protected]>> wrote:
This is situation is for a standard user on Windows 7. There is no such problem 
on pre-Vista Windows versions - and I assume the Windows 8 behaviour is similar 
to that on Windows 7.
I want to use the Microsoft.VisualBasic assembly's FileSystem.Delete method 
universally, but can't work out how to get around the problem that the 
RecycleOption.SendToRecycleBin parameter is overridden once permission is given 
by the user to delete the file, when that file is in a restricted location like 
the root directory.

My.Computer.FileSystem.DeleteFile(TestFilePath,
                                  FileIO.UIOption.AllDialogs,
                                  FileIO.RecycleOption.SendToRecycleBin,
                                  FileIO.UICancelOption.ThrowException)
If TestFilePath is "C:\test.file" then the usual security dialog occurs, and on 
continuing & giving permission the file is deleted - but permanently.

On the otherhand, in a location like the user's desktop



     (Environment.GetFolderPath(Environment.SpecialFolder.Desktop) & 
"\Test.txt")
it does get deleted to the recycle bin.
How can I have the files always go to the recycle bin (assuming the user gives 
permission, as required)?
________________________________
Ian Thomas
Victoria Park, Western Australia


Reply via email to