odrive will not unsync when a folder or sub-folder or file is read only. Read only files can be dealt with by opening properties, but to clear the read only attribute for a folder or sub-folder one needs to us the command prompt attrib command. Like this:
attrib -R d:[userid][path. In double quotes if spaces][top folder name in double quotes if spaces]*.* /S /D
This will clear the read only attribute on all folders and files under the top folder, including the top folder.
I notice a thread in the forum where odrive did not know this.
So odrive should document this.
Better still, when a read only is encountered, odrive unsync should give the option to ignore the read only for this file/folder or for all files/folders and then continue and delete the files/folders.
Even better yet, odrive should just automatically ignore the read only attribute. After all, the user want to unsync and the read only does not really apply in this case.
And windows 10 seems to set the read only attribute a lot.
Since odrive needs to perform a delete of the object, then add the placeholder file, it needs to be able to perform the delete and write operations. When the read-only attribute is set it will prevent this from happening.
This is not something we will override since we assume that the object is set this way for a reason, either by the user, by an app, or due to system policies.
Can you point me to this thread? Generally we would ask the user to unset the read-only attribute on the folder hierarchy using a “right-click->properties->uncheck Read-only” and then choose the “Apply changes to this folder, subfolders and files” in the subsequent pop-up box since it is easier than using the command line.
Hi Tony. To start with, the properties Read only flag only applies to files, not folders, as it states. And it is easily tested. So the only way to change the read only flag on the folders is to use the command prompt. And since the user wants to unsync, you can safely assume he wants to do it. And windows 10 seems to set a lot of folders as read only whether the user wants to do that or not. So you would be doing your users a favor by allowing the deletion, perhaps by my better still suggestion above. Not all users know about the command prompt and how to use it, or maybe they don’t want to for fear of messing something up. So help them out. Even if it is a system file or set read only by an app, the system, or by policy, the file has been copied or moved! into the odrive folder, and is now in the wrong place, so you should go ahead and delete that anyway.
Did you know that File Explorer will happily delete read only files and folders? Without even a warning. The least you could do is ask the user if they really want to, and give them the option to do the action for all similar files and folders. And really, you are not deleting the file, you are moving it. In order to move it, yes you need to copy then delete, but moving is different than just deleting - the file still exists.
On the thread, I think I was searching for read only.
I know the read-only attribute on a folder are treated differently than a file, but we can definitely refer people to some official Microsoft articles if they run into a situation where unsetting via Explorer doesn’t solve their specific issue.
When it comes to deleting data we generally err on the side of caution. I don’t think we will end up trying to override these settings, ourselves. If the OS returns an exception when we attempt to make the change, we will defer to the OS as the authority in that matter instead of trying to circumvent it. I realize that this may be an inconvenience, but it is better than odrive making the wrong assumption and then causing a bigger problem down the road.
Well this will my last post about this, as it seems odrive has a misunderstanding about what the Read-only attribute is for.
But your first link actually makes my case:
"Note Unlike the Read-only attribute for a file, the Read-only attribute for a folder is typically ignored by Windows, Windows components and accessories, and other programs. For example, you can delete, rename, and change a folder with the Read-only attribute by using Windows Explorer.
The Read-only and System attributes is only used by Windows Explorer to determine whether the folder is a special folder, such as a system folder that has its view customized by Windows (for example, My Documents, Favorites, Fonts, Downloaded Program Files), or a folder that you customized by using the Customize tab of the folder’s Properties dialog box. "
You are confusing Read-only with a do not delete. Two different things, as noted in the quote above. And you are not following the windows definition of Read-only on a folder. You have no problem with users turning off the Read only attribute easily on files, but make them work for it on folders. Rather inconsistent actions on your part.
I just want to clarify that we aren’t evaluating the file/folder attributes and making up our own rules or interpretations on what those mean.
We simply try the delete action, regardless of attributes. That action is either allowed by the OS, or an error is returned by the OS. In this case, if there are files that are set to read-only, Windows will reject the delete command odrive attempts and then odrive will abort the unsync operation.