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: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] 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. 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: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] 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: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] 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).as px, but I'm not certain. Greg On 17 October 2013 20:16, Ian Thomas <il.tho...@iinet.net.au> 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
