using digikam 6 on windows10 I am placing a prior collection of image folders and folder of 4 databases onto C:drive
I intend to do no editing of original files, presentation only, and only metadata writes to database
I would prefer to keep image files as read only but the remapped digikam collection already fails to show full images in preview. Only the prior generated thumbnails with tags are displayed.
I have learned there is a flaky readonly attribute in win10 which can be ticked off for a folder folders but then revives
https://answers.microsoft.com/en-us/windows/forum/all/how-do-you-remove-write-protection-on-a-folder/76373111-c71e-41e6-9b47-7451bdc9f9bf?page=2
Is this the cause of the failure to show full image previews from the image folders?
"The storage location of this image is currently not available"
Is there some scan or rescan function required?
I simply pointed the local collection path to the proper folder (with subfolders) (all with having zombie readonly attribute)?
I do not intend to edit and how could preview be a pretext for editing?
Even if thumbnails show now , if I add photos will the thumbnail file be written to with a zombie attribute?
i dont understand if "not available" files stems from win10 zombie features or digikam calling "preview" an edit function?
I would be using linux but win10 required
Ty

The behavior described in this post was solved by two corrections
First the permissions problem: From the link in the opening post perhaps its fair to say that the readonly attribute for FOLDERS is ambiguous and confusing. The 4 digikam databases were moved from a backup thumb drive and to various locations in the directory structure of the hard drive.
As long as the digikamrc config file points to that folder of 4 databases digikam can startup as a program however when a user toggles the folder attribute on and off multiple times it is easy to accidentally convert all recursive down stream folders (and files) to read only. Whenever the primary digkam4 becomes readonly as a FILE attribute it will be impossible to do any rescan or synchro functions which are under the Menu TOols Maintenance. So a moved digikam4 file can become a readonly barrier even if the digkamrc config has been edited to point to digkam4 file that properly belongs with a given tree of image folders.
Second problem : "The storage location of this image is currently not available"
This message is too general to give guidance to the specific cause.
I knew that I had force fed digikam to accept the SQL database that had been moved around on different devices, so I first tried to add a type 1 album root and that process did not complete. I found that the SQL database contained a wrong ALBUM ROOT field that also was pointing to an album type 2 which means portable media. I used DB Browser for SQLite to study the field structure of digikam4 and to edit the AlbumRoots table at the field "identifier" which contained the old volumeid of some now misplaced thumbdrive and corrected to the volumeid for the harddrive of the new workstation. I also had to manually edit the specific path . This allowed digikam to deliver full Preview images in the previously blank Preview real estate. This single field in the fundamental first table of the SQL can be the stumbling block when moving image collections (and a working SQL onto a new workstation.
Presumably the Settings >Database Migration is the tool for moving an AQL along with a bunch of image folders. However it is easy to get lost and unable to interpret sparse terse user feedback during an operation and direct forensic study of the SQL can lead the way out
DB Browser is helpful also to looking at the scale of duplication or blank regions in a database before carrying out Tools>Maintenance actions.
It would be helpful if the digikam program offered more feedback to inform the user before choosing such actions