manifest.json makes no-op changes on disk very frequently about userscripts HOT 3 OPEN

The current native checks and updates may be more frequent and cause issues such as #557.
But this is probably the best option with the current logic and without a lot of refactoring.

To completely solve these problems requires a more comprehensive process design and refactoring.
Let's keep this issue open so that we don't forget to consider this when doing related works.

from userscripts.

For the first point, it's not a bug, but it is indeed one of the issues that should be addressed when we plan to update the backend process in the future.

Essentially, it was introduced in #525. When you focus the Safari window, it checks the script files for changes in the background and updates the manifest file. So if you don't switch focus to Safari, that won't happen.

For the second point, that might keep the file contents from changing (in the case you describe), but probably won't avoid the fact that the file is written.

A better approach might be to stop writing to the file when it's confirmed that nothing has changed, but that might require some process refactoring.

One problem is that currently the file is not designed to be modified by the user, or used for synchronization purposes. Modifying it may cause unexpected behavior. For example, you may find that modifying some settings may not take effect.

We are indeed considering using a new manifest file in the scripts folder to synchronize settings in the future (maybe).
In the latest beta version, we have added the import and export function of settings data.

So, for this issue, I will see how to solve it when refactoring the relevant parts. However, it is currently not recommended that you synchronize and modify this file. Synchronizing only the scripts folder is a good option for now.

from userscripts.

That's really good context, thank you! #523 helped me understand why nativeChecks is useful.

For my use case, I'll just sync the scripts folder as you recommend — I'm totally happy with this outcome, so you're welcome to close the issue if it isn't useful for tracking.

You make a good point that checking the file for changes before writing it would be a better change than just sorting the file. I'm thinking here of lower-level observers like rsync or the filesystem itself, which may perform extra work if a file's inode changes. I think rsync, for example, uses inode timestamps by default (rather than file contents) to decide which files to skip, so just sorting the file wouldn't help there.

from userscripts.