ATTENTION: You are viewing a page formatted for mobile devices; to view the full web page, click HERE. Software > Clipboard Help+Spell

Clipboard Help+Spell errors

<< < (4/5) > >>

@Ath + @Shades: Thanks for trying to help.

The files (in the CHS database) in question are definitely unticked in the Read-only attribute. I have double-checked this, as I initially thought that would probably be the problem, even going so far as to enforce them to be unticked again. It made no difference though.

The files are in a directory on the C:\  drive, which is where they have always been since I started using CHS. The drive location has never been a problem before, anyway, so I don't see how/why it could be a problem now. It doesn't seem to be a problem, at any rate.

While the 'Properties' screen of a file shows the attributes set for that file, that is not necessarily the way how that file is treated in day-to-day use. There is a tool SetACL Studio, (the company gives away a full license for that tool) that shows you how the access right for any file or folder are really managed by Windows. It also allows you to make adjustments and it is a much nicer interface than the default tools that Microsoft delivers with Windows.

It might be an update of Windows 10 that adjusted/resetted the ACL (Access Control List) for files/folders on your C:\ partition.

Having migrated/copied across to another PC, CHS is getting the error:
--- End quote ---

this does sound like a problem where you might have CHS running from (or trying to save to) a directory that it does NOT want to allow access to, assuming you are using portable=true.

a good first thing to try would be to move it to another directory where your user files are and see if you have the same problem.

yet another thing to check is the "Backup/Maintenance" tab, and look where it says "Directory where backups should be stored" and the line under that where it tells you the ACTUAL DIRECTORY it is trying to use to store backups -- make sure that is a directory that an app can write to.

And also the "Tweaks" tab, look for "Temporary DB file location" and try changing that.

If these still fail, let us know the full directory where you are running CHS from.

@mouser: Thanks for your comment. I put my Sherlock Holmes hat on and went through the checks you suggested to verify what directories are being accessed/written to, and have now figured out and fixed the problem and discovered what seems to be a quirk in CHS. It's quite interesting:

* Context: I have migrated CHS from a laptop with an oldish version of Win10-64 Pro to another laptop with a more up-to-date version of Win10-64 Home.
Problem: CHS consistently fails with the DBISAM error above and all previous settings are lost.

* CHS directory:
My user ID is the Owner of the FARR directory and subdirectories at:
       C:\UTIL\Windows utilities\FindAndRunRobot\
These directories are all unchecked for Read-only.
The location of CHS is in the plugins folder of FARR:
       C:\UTIL\Windows utilities\FindAndRunRobot\Plugins\Clipboard Help+Spell\

* CHS Database:
The CHS Database path is:
       C:\UTIL\Windows utilities\FindAndRunRobot\Plugins\Clipboard Help+Spell\Database\

* CHS Backups:
The CHS Backups path is:
       C:\UTIL\Windows utilities\FindAndRunRobot\Plugins\Clipboard Help+Spell\Backups\

* CHS Tweaks: Is set to Force to system Temp directory - for potentially fastest response time.
NB: System Temp is ImDisk, a dynamically variable-sized RAMdisk (up to 2GB) - in R:\Temp and which is set as the system default Temp/TMP directory.
Changing CHS Tweaks to either:
        Let database engine decide, or
        Use Database "Temp" subdirectory
 - fixes the problem and all the previous settings are restored OK.

* The reason for this is explained by a warning in the ImDisk configuration tool:
Warning: the fast startup feature of Windows is enabled. This
can lead to some issues:
  • The system writes the ramdisk content onto the hard drive
     at shutdown, and restores it at startup.
  • The data synchronization feature of ImDisk Toolkit does not
     work at system shutdown.

Open the Shutdown settings to disable the fast startup.

(Button) Shutdown settings
(Checkbox) Do not t show this warning again                             (Button) CloseObviously, I want to keep the R:\Temp RAMdrive working, as it speeds up the the system, so I disabled fast startup.

* Gotcha in this version of Win10?:
The fast startup shutdown settings are greyed out (cannot be changed), but you can change them, except that it is sorta hidden on another page (I did a duckgo search to find that out). After disabling the fast start settings, the ImDisk configuration tool no longer gives the warning message. However, CHS still would not work with the R:\Temp setting, so I left the CHS Tweak set at Let database engine decide, (which works OK) - and the RAMdisk seems to work fine for all other applications (so far). Not sure whether CHS using the CHS Temp folder instead of the RAMdrive will slow CHS response times on some large database searches, but we shall see. However, it seems as though CHS is sensitive to the RAMdrive and doesn't like to use it, though it apparently worked OK on the previous laptop (with the older Win10-64 Pro). I would like CHS to use it, for optimum response, so that could be a something needing a workaround/fix, if/when you have the time to investigate, please.   :D

Thanks again.
CHS remains one of my daily most useful PIM tools and I was nearly overcome with despair when it wouldn't seem to work.

That's a fascinating discovery -- thanks for reporting it!
Following up, here's what I'd like to know the answer to: If you change back to the "system temp" directory that causes the error, but manually restart CHS after it has booted, does the error disapear?
If so, and the problem is only that at early BOOT time the system temp directory causes trouble, another solution would be to have CHS start up late in the boot process (by using a 3rd party tool for that or otherwise doing it), instead of having CHS do its own operation to start at bootup time.

Having said that, I would worry that if CHS is having this error trying to reach the system temp drive, maybe other apps could too -- but in a way that might not be so obvious..


[0] Message Index

[#] Next page

[*] Previous page

Go to full version