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 <il.tho...@iinet.net.au> 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:* 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 <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 <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).aspx, > 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**** > > ** ** >
