No announcement yet.

FILEATTR and Windows-10

  • Filter
  • Time
  • Show
Clear All
new posts

  • FILEATTR and Windows-10

    I make extensive use of FILEATTR in this format:

    GETATTR(FileName$)=32 THEN SETATTR FileName$

    and since XP thru W7, all has been well.

    But, a customer recently upgraded to W10 Pro and my application hangs at the above line without producing any sort of error. This does not happen on every incidence of W10 as other customers have no problem with their W10.

    The question is would anyone know of a Windows environmental issue that may be causing this? As PB doesn't even create an error at that line, I flummoxed about how to even figure what's happening. Removing the line allows the application to proceed as normal without having set the attribute to 'Normal'.

  • #2
    What happens when you replace -
    … SETATTR Filename$
    with -
    … SETATTR Filename$, 0


    • #3
      Give me a few days to try...


      • #4
        Does the user have modify rights on the file/directory in question?


        • #5
          Originally posted by Stuart McLachlan View Post
          Does the user have modify rights on the file/directory in question?
          Yes. Prior to this problem, the user (with my app) has already written a pile of stuff into a log. Indeed, I added vastly more detail to the logging pretty well every line of code before discovering where it was hanging. So am sure it's not a permissions issue.


          • #6
            Originally posted by Owen English View Post
            I make extensive use of FILEATTR in this format:

            GETATTR(FileName$)=32 THEN SETATTR FileName$
            This shouldn't compile as according to the docs, the syntax is SetAttr (filename), file attribute


            • #7
              A few things can be done over the phone.

              Is run as admin required for the shortcut?

              Might get to a command prompt and TYPE ATTRIB filename to see if the file is system or read only.
              Note: If any code uses kill, it will return 0 on system or read only files and not kill the file.

              Type WINVER at command prompt or in run dialog to report Windows 1903 (OS Build 18362.387 or such.)
              Hopefully they are using the same version as you and not one of those earlier pesky versions.

              If still can't fix, Backup and then run CHKDSK C: /F
              Then there is the possibility of a virus checker doing something.

              Some test code, good luck
              FUNCTION PBMAIN () AS LONG
               LOCAL sFileName AS STRING
               sFileName = INPUTBOX$("File to test",EXE.FULL$,"")
               IF LEN(sFileName) THEN TestAttrib(sFileName)            
              END FUNCTION
              FUNCTION TestAttrib(sFileName AS STRING) AS LONG
               LOCAL attr AS LONG
               IF ISFILE(sFileName) = 0 THEN ? USING$("& not found",sFileName),,"Done":EXIT FUNCTION
               attr = GETATTR(sFileName)
               ? USING$("File attribute of & is #",sFileName,attr),,"TEST 1 OF 2"
               SETATTR sFileName, 32
               IF ERR THEN
                 ? USING$("SETATTR error # of file &",ERR,sFileName),,"DONE"
                ? "Set fle attribute to 32",,"DONE"
               END IF
              END FUNCTION
              How long is an idea? Write it down.


              • #8
                Originally posted by Knuth Konrad View Post

                This shouldn't compile as according to the docs, the syntax is SetAttr (filename), file attribute
                My apologies, my OP should have read: IF GETATTR(FileName$)=32 THEN SETATTR FileName$, %NORMAL
                Last edited by Owen English; 1 Oct 2019, 02:56 AM. Reason: Typo - thanks Stuart!


                • #9
                  Originally posted by Owen English View Post

                  My apologies, my OP should have read: GETATTR(FileName$)=32 THEN SETATTR FileName$, %NORMAL
                  Presumably with an IF in front as well?


                  • #10
                    I am in the process of migrating files from Win7 and setting up on a new Win10 machine, and I am having the same or a very similar problem as described above... My program can create the new destination folders, but doing FILECOPY of files into those new folders consistently fails with an Error 70 - Permission Denied. Checking the new folders' Properties reveals that yes indeed, they are all set for Read Only. However, I have explicitly requested the attributes remain NORMAL...

                    MKDIR sDestIndividualFolder
                    SETATTR sDestIndividualFolder, %NORMAL
                    ? "Attributes of: " & sDestIndividualFolder & " = " & STR$(GETATTR(sDestIndividualFolder))
                    reports 16, which is %SUBDIR. Yet checking the folder properties again show it's still ReadOnly. This ReadOnly status is NOT VISIBLE to my PB GETATTR statement!

                    Next, "RUN AS ADMINISTRATOR", and again the error, and the folder remains ReadOnly.

                    Downloaded the "Take Ownership" registry hack ( (which worked great in Windows 7), and still no joy.

                    (I understand that the level of permission of my user account (administrator) has no influence on the running EXE (it's been discussed at length in other threads), so I have no expectations about changing the user account.) What I need is to enable the EXE to have the proper permissions for copying files...

                    As I wrote that, I remembered other threads that discussed UAC issues, and because I threw this together as a quick utility I didn't have a Version Info block and manifest, so I went back and added them. …Still no joy, even when "RUN AS ADMINISTRATOR"...

                    Also odd that under Properties when I reset the attributes, they don't "stick". I can unset the R/O box (with confirmation panel), and immediately re-check, and the R/O attribute has not remained unset!

                    OK, the destination folder is under two levels of folders on the Desktop, so maybe there's some built-in automatic protection? (These are shortcuts being copied from another location, and are intended to be run from the desktop.)

                    I'm obviously missing a key piece of information...can anyone clue me in?



                    • #11
                      Here's the Win10 manifest I'm using. I know nothin about what's in manifests. I swiped this one from another thread. It ws designated as a Win10 version...

                      <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
                         <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
                            <assemblyIdentity version=""
                            <description>Optional description of your application</description>
                               <asmv3:windowsSettings xmlns="">
                            <!-- Compatibility section -->
                            <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
                                  <!--The ID below indicates application support for Windows Vista -->
                                  <supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>
                                  <!--The ID below indicates application support for Windows 7 -->
                                  <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
                                  <!--This Id value indicates the application supports Windows 8 functionality-->
                                  <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>
                                  <!--This Id value indicates the application supports Windows 8.1 functionality-->
                                  <supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/>
                                  <!--This Id value indicates the application supports Windows 10 functionality-->
                                  <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>
                            <!-- Trustinfo section -->
                            <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
                                     language="*" />


                      • #12
                        OK, so I changed my destination folder

                        from: sDestRootFolder = "C:\Users\john_\Desktop\FENCES"

                        to: sDestRootFolder = "D:\test\FENCES"

                        and it worked the same, and reported 16 (SUBDIR)…

                        AND, I tried going in to Properties/Security, and ensuring all users have Full Control, but STILL NO GOOD! As soon as I finished changing permissions, I checked back right away, and my changes were ignored. EVEN on my D Drive, where the OS has no built-in interests.

                        OK, I'm at the end of a long day (USA, Eastern), so I'm going to get some sleep and come back to this in the morning...

                        G'night all!


                        • #13
                          Alright, one last thing I checked... EVERY FOLDER on my D drive is set to Read Only, and I cannot undo it on ANY of them, even though I set up the drive and copied files.

                          AND!!!! Even my external hard drive shows EVERY folder as ReadOnly!!!

                          In the morning, I'll move the external HD to my Win7 computer and see if the folder properties are back to normal...

                          Win10 is VERY intrusive!



                          • #14
                            Could be anti-virus.
                            How long is an idea? Write it down.


                            • #15
                              Thanks for that link, Mike.
                              I've done every procedure they suggest, and still, EVERY folder is RO, and although my program is able to create the new folders, it cannot copy anything into the folder. Even a new root-level folder inherits RO from somewhere...

                              Argh! I should have gone to Linux...



                              • #16
                                Take ownership of the items, then you can change the access rights.
                                <b>George W. Bleck</b>
                                <img src=''>


                                • #17
                                  Nope, there's a much bigger problem here...

                                  I've been reading and trying all kinds of things, even going to Security and inheritance settings.. All to no effect. Well, that's not entirely true - I can see the permissions and ownership change, but still everything comes up ReadOnly. There's something else that overarches all these normal fixes.

                                  So after reading dozens of articles, I think I've narrowed it down to the way that OneDrive and Office365.take over everything local in order to share files, including my entire D drive that has always been my own territory.

                                  I haven't got it figured out yet, but there's hope in the direction of stopping OneDrive and Office365 from sharing and synching. That's the next step.

                                  I'll keep y'all posted.

                                  Wish me Linux, er, luck!


                                  • #18
                                    You subscribed to Office 365?

                                    Reimage the computer.

                                    OneDrive probably not a good idea either.

                                    (Another alternative, wait two weeks. If enough people complain , the next Windows update will fix what the last one broke. (Don't get me wrong, I like Windows, but Microsoft does not hire product testers. WE ARE THE TESTERS!))


                                    • #19
                                      On my system every folder shows read-only checked even though it says this... [X] Read-only (Only applies to files in the folder)
                                      If I look inside that Read-Only folder there are other Read-Only folders and files that are not read-only.

                                      I would venture to say that you should not consider the folder as being completely Read-Only based on what properties are showing for the folder.
                                      Likely every folder that contains a folder or more will show a property of Read-Only.

                                      To confuse you even more...

                                      My Weather folder is said to be Read-Only but it contains no folders just files with normal attributes.
                                      In other words I would not assume a Read-Only folder contains anything (files or folders) that are Read-Only.

                                      The Folder Attribute merely indicates that the Folder itself is protected somewhat.

                                      You should only be looking at the file in question. Not the folder properties.

                                      This is how I handle replacing on old file...
                                                case "xptheme_New.xml"
                                                    if FileExists(Pathz + "\xptheme_New.xml" + $NUL) then   '<== new file
                                                        IF DeleteThisFile(Pathz + "\xptheme.xml" + $NUL) THEN  '<== delete old file
                                                            SETATTR Pathz + "\xptheme_New.xml", 0  '<== set new file attributes
                                                            NAME Pathz + "\xptheme_New.xml" AS Pathz + "\xptheme.xml"  'rename new file
                                                            'CALL FLASH_NOTE_FOR_SECONDS("The XP theme was recovered.", 1)
                                                        END IF
                                                        'CALL FLASH_NOTE_FOR_SECONDS("The XP theme has not changed.", 1)
                                                    end if
                                      More possibilities here.
                                      Since, "I am in the process of migrating files from Win7 and setting up on a new Win10 machine,"
                                      George's Post #16 has the right idea.

                                      It seems like every time there is a massive Win10 update I have to do that. Permissions and ownership get skewed. Likely an artifact from removing Windows HomeGroup. That is why I'm not looking forward to this spring's update. They say it will be another massive one.
                                      Last edited by Jim Fritts; 16 Apr 2020, 09:06 PM.


                                      • #20
                                        Thanks Jim,

                                        I cannot tell you how much I appreciate your examining your own system and reporting that you see the same I'm seeing... But it leaves me wondering why my program can't copy the files...

                                        I'll give these ideas and links a shot tomorrow... It's been a grueling day, and I'm knocking off early tonight to get some much needed sleep!

                                        Thank you!

                                        BTW, I found a setting in File Explorer that bypasses the OneDrive synch for a folder/file, something like "keep on this device". I'll report the details in the morning.