Project suddenly becomes write-protected

[ingrid hughes]

Hi,

I've been working on a project for weeks off and on, and suddenly today, I went to add a new topic and got a message saying I couldn't because the file was write-protected.


When I click OK in the error message, I get this error message:


Then a red bar appears across the top of the editor and I can't delete the file. It appears in the ToC, greyed out, but not in the Topics files.
How do I fix this?

Ingrid

[Alexander Halser]

The topic is most probably being edited by another user. Try to rename the topic file manually in Windows Explorer (navigate to the location of the project, find the \Topics folder and the file "Viewing-Graphics.xml").

Try to give it a different name in Windows Explorer, for instance from "Viewing-Graphics.xml" to "Viewing-Graphics2.xml". If you are successful, rename it back. But I think you won't be able to do that. And if Windows doesn't let you modify the file, Help+Manual cannot, either.

[Tim Green]

Hi Ingrid,

In addition to the possibility that another user is on the project, the most frequent recent cause for this is trying to edit your project in a OneDrive cloud folder. This has become very bad recently and OneDrive will always make your projects uneditable. If this is the case you need to copy (NOT MOVE!) the entire project to a folder in your own Documents directory (be careful, OneDrive tries to pretend it's your Documents directory) and then use Windows File Explorer to reset the read-only attribute of all the files in the project folder. Here are full details:

ABOUT ONEDRIVE AND OTHER MANAGED CLOUD FOLDERS

Problems with Help+Manual projects caused by OneDrive have become much worse recently, to the point that editing Help+Manual projects in OneDrive folders is now a 100% guarantee for serious problems. This applies even for projects not under version control, but the combination of OneDrive and version control is much worse. So here is what you need to know:

Do not ever try to edit Help+Manual projects in OneDrive (the absolute worst culprit) or any other managed cloud folder like iCloud Drive, DropBox or Google Drive!! You will get corrupted files, lost data, strange errors with locked files and other problems. If you then combine this with management by version control you can experience even more serious problems. You are relatively safe with single-file HMXZ projects, so long as they are not open in OneDrive on another computer, but It gets (very) problematic if you are using the uncompressed HMXP project format, with access to OneDrive on more than one machine.

SOLUTION FOR PROJECTS NOT UNDER VERSION CONTROL:

Copy (do NOT move!!) your entire project folder to a directory outside of OneDrive's control where your Windows account has full read/write/modify permissions. Then select the new folder in Windows File Explorer, right-click and select Properties and remove all read-only attributes on all files in the folder. You need to copy rather than move because if you move all the files will come over with the unchangeable file locks applied by OneDrive.

SOLUTION FOR PROJECTS UNDER VERSION CONTROL:

If possible, delete the entire project folder in the OneDrive directory. Do NOT try to move or copy it. If it cannot be deleted (this is possible), mark it clearly that it should not be used. Then download a fresh copy of the project from the repository into a new empty folder in the user's own normal local Documents directory.

ADDITIONAL PRECAUTIONARY MEASURE FOR PROJECTS UNDER VERSION CONTROL:

If the user with the OneDrive copy has synchronized with the main repository this may have introduced OneDrive issues into the repository. In this case it is best to abandon this repository and create a fresh one. This should be done by a user with a clean copy of the current state of the project. Before creating the new repository from this project copy all the files and folders in the project to a new location, WITHOUT the .git or .svn version control management folder.

More background:

OneDrive and other managed cloud folders are fine for archiving and transfers, but they are generally only safe for active editing with programs that are specifically designed to interact with them. In the case of Microsoft that is only Office and some other Microsoft programs. They don't provide access for third party developers. It's similar with Google Drive, which only works reliably with Google's own applications like Google Docs.

Even on systems like DropBox that do provide some third party access, it does not work very well. For example, the Scrivener novel-writing tool has a similar structure to Help+Manual, but with RTF files instead of XML. They have added literally thousands of lines of code to try to get Scrivener to play nice with DropBox, but it still only "works" if you never ever open a Scrivener project on more than one computer linked to the same DropBox. If you do -- even if one copy simply remains open on another computer because you forgot to close it -- you get a horrible mess of "conflicted copies" of the text files that is very difficult to untangle, because each copy contains a different editing status.