none
Trying to SetAttr of files needing "Admin" access causes program to hang. No error. Help. RRS feed

  • Question

  • Nearly a decade ago, I wrote a little utility to automatically delete all files from a folder of my choosing that are older then a certain number of days (also of my choosing.) It's mostly for automatically deleting old TV recordings so the folder doesn't fill up forever, but I love using it for temporary storage. I've updated it over time but it has worked like a charm for years.

    Today, I finally got around to trying to add the ability to delete folders too... something that has eluded me for years. So I updated my code to first reset any folder attributes back to normal, after which it is supposed to delete the folder and it's contents.

    Unfortunately, during testing on a folder containing "protected" files (despite Windows showing all attributes normal), when I try to reset the attributes, the program simply hangs like it is stuck in an endless loop. No error, and no files/folders are changed.

    Dim di As New DirectoryInfo(strCachePath) ' Path read from .ini file.
    Dim diArr As DirectoryInfo() = di.GetDirectories()
    Dim dri As DirectoryInfo
    For Each dri In diArr
        strFilename = dri.Name
        If InStr(LCase(strFilename), "safe-") <> 1 Then  ' Ignore folders tagged as "safe".
            dteGetDate = dri.CreationTime.Date
            dteToday = Format(Today, "d")       ' Strip time from date.
            dteDays = Format(dteGetDate, "d")   ' Ditto
            intDateDiff = DateDiff(DateInterval.Day, dteDays, dteToday)
            If intDateDiff > intDays Then
                strCachePath = strCachePath + "\" + strFilename ' Target folder with path.
                ' ***** PROGRAM HANGS on next line! *****
                FileSystem.SetAttr(strCachePath, vbNormal)  ' Clear any Read-Only or "Hidden" attributes.
                FileIO.FileSystem.DeleteDirectory(strCachePath, FileIO.DeleteDirectoryOption.DeleteAllContents, FileIO.RecycleOption.DeletePermanently)
            End If
        End If
    Next dri

    When I test, the folder in question is: "D:\Recorded TV\TempRec\TempSBE\" containing two 500MB files (all attributes already cleared):

    "{2426ECEF-CBF4-49F0-9486-ED1027B120A8}.tmp.sbf"
    "{FE3C930D-A7CD-4FBB-ABCB-98C0890A4443}.tmp.sbf"

    If I try manually deleting the files by hand, I'm prompted for Admin access.

    If I skip resetting the attributes, the program simply hangs on the next line (trying to delete the folder & contents.)

    I've tried waiting several minutes for the program to resume but never does. I could run the program as Admin, but it's meant to run automatically at Startup, and being prompted for Admin access at startup is really bad form (annoying and potentially dangerous.)

    Is there any way around this? Even detecting such protected files/folders so they can be ignored would help (but I'd much rather delete them.) TIA



    Sunday, October 6, 2019 8:02 PM

Answers

  • Assuming there is nothing to catch is not valid justification of not using try/catch. There is no good reason not to use try/catch when there is potential for something to be thrown and in this case there is. Excuse me if this is rude, but it is sloppy to not use try/catch.


    Sam Hobbs
    SimpleSamples.Info

    Monday, October 7, 2019 2:57 PM

All replies

  • Hi,

    You can try my code to remove a single attribute(ReadOnly):

    Imports System.IO
    
    Public Class Form1
        Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
            Dim Path As String = "c:\test\MyTest.ini"
    
    
            Dim attributes As FileAttributes = File.GetAttributes(Path)
    
            If (attributes And FileAttributes.ReadOnly) = FileAttributes.ReadOnly Then
                attributes = RemoveAttribute(attributes, FileAttributes.ReadOnly)
                File.SetAttributes(Path, attributes)
                MsgBox("The {0} file is no longer RO.")
            Else
                File.SetAttributes(Path, File.GetAttributes(Path) Or FileAttributes.Hidden)
                MsgBox("The {0} file is now RO.")
            End If
        End Sub
        Private Shared Function RemoveAttribute(ByVal attributes As FileAttributes, ByVal attributesToRemove As FileAttributes) As FileAttributes
            Return attributes And Not attributesToRemove
        End Function
    End Class
    

    Best Regards,

    Alex


    MSDN Community Support Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Monday, October 7, 2019 2:02 AM
  • Hi,

    You can try my code to remove a single attribute(ReadOnly):


    Thanks for the reply. However "Read Only" isn't an "Admin Level" attribute. I can already clear/reset those. :(
    Monday, October 7, 2019 3:28 AM
  • The remarks for the FileSystem.SetAttr(String, FileAttribute) Method says A run-time error occurs if you try to set the attributes of an open file.

    Is that possible? Could the file be open? It is not clear if you are saying it is a folder that it hangs on but it would make sense that it could not delete a folder containing an open file.

    I do not know the VB syntax for try/catch but programmers often are lazy about doing things like that. I know I was. Try catching errors from that line and anywhere there might be an error. Windows has no choice other than to escalate an error after it has been ignored.



    Sam Hobbs
    SimpleSamples.Info

    Monday, October 7, 2019 4:11 AM
  • The remarks for the FileSystem.SetAttr(String, FileAttribute) Method says A run-time error occurs if you try to set the attributes of an open file.

    Is that possible? Could the file be open? It is not clear if you are saying it is a folder that it hangs on but it would make sense that it could not delete a folder containing an open file.

    Thanks for the reply.

    The files are not open or in use. That would produce an error I could catch.

    No, for some reason, Windows identifies the files inside the folder as requiring Admin access before modifying (in this case, they are simply data files used by a program I deleted years ago.) So when my program tries to SetAttrib or Delete the files, it simply hangs. No error. No prompt for Admin access. It just sits like it's in an endless loop.

    I'd prefer to be able to delete the files, but even having a way to identify them as requiring Admin Access before I try modifying them (and cause the program to hang) would be helpful.


    Monday, October 7, 2019 12:32 PM
  • In File Explorer open the property sheet for the files and select the Security tab.  You can then inspect the file's ACL to see exactly which users/groups have access and what level of access is allowed as well as which user is the owner of the file.
    Monday, October 7, 2019 12:41 PM
  • Nearly a decade ago all folders in Windows were  available for a programmer. That has changed, even in Houston there is probably political hacking, moreover everywhere on the world there is hacking for fraud.

    It means that more and more folders are closed for user programs. For instance the root C:\ (boot) drive folder and the Program.files folder are protected to write of change. 

    Therefore currently you have to prevent that those folders are in those operations.  

     

    Success
    Cor

    Monday, October 7, 2019 12:43 PM
  • In File Explorer open the property sheet for the files and select the Security tab.  You can then inspect the file's ACL to see exactly which users/groups have access and what level of access is allowed as well as which user is the owner of the file.

    Thanks for the reply.

    Manual security access isn't an issue. If I try to delete the file by hand, I'm prompted for Admin access and should be able to delete it but I haven't tried because I need it for testing. (Making a copy doesn't help me because I can do whatever I want to a copy.)

    The files themselves are hidden inside a hidden subfolder inside a hidden parent folder.

    Monday, October 7, 2019 1:05 PM
  • That would produce an error I could catch.

    You seem to be ignoring something important I said.



    Sam Hobbs
    SimpleSamples.Info

    Monday, October 7, 2019 1:22 PM
  • Earlier you wrote "No, for some reason, Windows identifies the files inside the folder as requiring Admin access before modifying (in this case, they are simply data files used by a program I deleted years ago.)"

    So I thought that inspecting the ACL would help you determine why this is so.

    Monday, October 7, 2019 1:40 PM
  • That would produce an error I could catch.

    You seem to be ignoring something important I said.

    .
    I didn't mean to sound like I was ignoring your point. I thought my response addressed it.

    The file is neither open nor in use. As I noted, the original program that created it was uninstalled years ago, and no other program reads the filetype.

    And (also as noted), if the file WERE open or in use, trying to mod it would produce an error that I could catch. No error is being produced so there is nothing to Catch.

    Monday, October 7, 2019 2:34 PM
  • Earlier you wrote "No, for some reason, Windows identifies the files inside the folder as requiring Admin access before modifying (in this case, they are simply data files used by a program I deleted years ago.)"

    So I thought that inspecting the ACL would help you determine why this is so.

    .
    Thanks, but all the Security tab on the file tells me is I have Admin access to the file, not why Admin access is required.

    But how would that enable my program to identify/modify such files?

    Remember, this program simply does a simple delete of files/folders that are older than a predetermined number of days. There is no way to know in advance what files it might encounter.

    Monday, October 7, 2019 2:41 PM
  • Assuming there is nothing to catch is not valid justification of not using try/catch. There is no good reason not to use try/catch when there is potential for something to be thrown and in this case there is. Excuse me if this is rude, but it is sloppy to not use try/catch.


    Sam Hobbs
    SimpleSamples.Info

    Monday, October 7, 2019 2:57 PM
  • Thanks, but all the Security tab on the file tells me is I have Admin access to the file, not why Admin access is required.

    But how would that enable my program to identify/modify such files?

    Remember, this program simply does a simple delete of files/folders that are older than a predetermined number of days. There is no way to know in advance what files it might encounter.

    If the ACL for the folder/file(s) only grants the Delete privilege to System and Administrators that is why Admin access is needed.

    There is no way for any of us to know why the old application that created the folder/files set up the security descriptor this way unless you are talking about a well-known folder where Windows would create such a security descriptor by default, and I don't recognize "D:\Recorded TV" as such.

    Monday, October 7, 2019 3:36 PM
  • I don't recognize "D:\Recorded TV" as such.
    The original program was TV tuner software, and I manually set the "Record To" location to a folder of my own making.

    Monday, October 7, 2019 4:54 PM
  • So why wasn't your application terminated due to the unhandled exception?
    Monday, October 7, 2019 5:08 PM
  • So why wasn't your application terminated due to the unhandled exception?

    Good question.

    I went back and revised my code to figure out why, adding code to manually recursively find & delete subfolders/files and got a different error telling me a particular subfolder requires Admin privileges to remove.

    Now that I can at least identify the error, I simply changed the Catch to alert the user (showing the path) and ignore the folder.

    Not the desired solution, but at least the program can continue w/o hanging.


    Monday, October 7, 2019 5:53 PM