It probably is. That links sort of pointing out that whilst you may think you're writing to the root (and other forbidden locations for a mere end user) Windows is silently putting it somewhere else. If you have a second app running with higher credentials that looks for the same file, it just wont find it.
On Sat, Oct 19, 2013 at 6:51 PM, Ian Thomas <[email protected]> wrote: > Thanks Mike. I thought that my situation is slightly different (but I am > not sure, now). **** > > That is a helpful and interesting blog post by Yochay Kiriaty – I will go > to the more expanded MSDN article (for VISTA) and may also see there the > missing images from his post. (It was 2009, and images do get displaced) > **** > > ** ** > > http://courteous.ly/aAOZcv ? Also inaccessible.**** > ------------------------------ > > **Ian Thomas** > Victoria Park, ****Western Australia******** > > ** ** > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *mike smith > *Sent:* Saturday, October 19, 2013 2:32 PM > *To:* ozDotNet > *Subject:* Re: Problem with FileSystem.DeleteFile method in root directory > **** > > ** ** > > > http://blogs.windows.com/windows/archive/b/developers/archive/2009/08/04/user-account-control-data-redirection.aspx > **** > > ** ** > > This one puzzled me for ages for one app.**** > > ** ** > > On Fri, Oct 18, 2013 at 5:51 PM, Ian Thomas <[email protected]> > wrote:**** > > Maybe as Ken Schaefer suggested, my problem *does* directly relate to the > inability to restore the file after being deleted from the root directory, > by a standard user (one the user doesn’t have UAC permission there). **** > > It is necessary for me to go through the UAC business, both as standard > user employing the File Explorer to delete my test file C:\test.txt, and in > any of my code tests to do the same. **** > > So, as Ken suggested, that might dictate whether the file goes into the > recycle bin or not. **** > > **** > > OK – taking just 2 minutes, switching user to Admin and deleting a file > C:\test.txt still raises the UAC dialogue, but no password is required; and > looking in the Recycle Bin, I see multiple *test.txt* files that have > been put there over the past few hours = whenever I have tackled this > little issue. **** > > As a standard user, those files were/are *invisible* to me. **** > > So – is the solution to my little dilemma to elevate the UAC rights just > for the case where files reside in such a location? Is that the only > solution? **** > > **** > ------------------------------ > > Ian Thomas > Victoria Park, Western Australia**** > > **** > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Ian Thomas**** > > > *Sent:* Friday, October 18, 2013 2:25 PM > *To:* 'ozDotNet' > *Subject:* RE: Problem with FileSystem.DeleteFile method in root directory > **** > > **** > > Ken - No, the user doesn’t have permission. As described by me in one or > other post, it is necessary to go through the UAC business. That souldn’t > affect anything. **** > > I’m not sure about “the inability to restore the file might dictate > whether the file goes into the recycle bin or not” – why would that be > so? And can it be averted? **** > > > > **** > > ** ** > > -- > Meski**** > > http://courteous.ly/aAOZcv**** > > > "Going to Starbucks for coffee is like going to prison for sex. Sure, > you'll get it, but it's going to be rough" - Adam Hills**** > -- Meski http://courteous.ly/aAOZcv "Going to Starbucks for coffee is like going to prison for sex. Sure, you'll get it, but it's going to be rough" - Adam Hills
