/hydrus/ - Hydrus Network

It isn't super important to do (it is like a db defrag), but that yours fails is not generally good news. Your client working otherwise suggests this is an unusual permissions issue rather than an actual problem though. Maybe an old instance of the client executable hanging around somehow?

This message suggests it is failing as soon as it opens the file, right when it starts–is this true, or do you get this error ten minutes into the operation?

If you shut down your client and go to install_dir/db and then run the sqlite3 executable and type this:

.open client.db
VACUUM;
.exit

How does that work out? Do you get a better error? You might like to try it for all four of the .db files there, although be warned that the mappings one will take a while to finish.

Unless we figure this out quick, you probably want to turn off the auto-vacuums for now under options->maintenance and processing.

>>8881

It's quick to stop, but anyway the "VACUUM;" command gives instantly a "Error: unable to open database file"

It's not read only, I just tried to give all users listed full control… then I tried running the sqlite executable as administrator and it worked. ffs. Right now I'm running the client as admin to run a full vacuum, but I'm not exactly comfortable with this workaround.

That aside the automated vacuum disabled itself the first time it tried to run, so there's that.

>>8889

This is breddy weird. Yeah, I don't recommend running hydrus as root. I assume vacuum needs to set some unusual file lock or something that your OS just isn't happy with in that location. Are you running your db from a network path or weird raid setup or anything odd like that?

EDIT: Aha, a bit of searching leads to this:

http://fredericiana.com/2014/11/29/sqlite-error-open-database-file/

Maybe the permissions on the actual directory?

I like SQLite a lot, but its errors are complete shit. If this is the problem, I'll test this myself and report the error better.

>>8895

I'm afraid it's not as easy, my setup is different: Windows 10 (64bit, but it's not like this thing runs on 32bit) and the install folder is J:\Hydrus Network and that's a common USB 3 hard drive. No fancy networking or raid arrays

>>8901

If you right-click->properties on the install_dir/db folder and check the 'Security' tab, does your username have read/write/modify permissions?

>>8903

*facepalm*

somehow my account wasn't there. Adding it to the whole install directory (with full control), this will take some time… I'll post the results when it's done.

Seriously though, Windows will be Windows, eh?

>>8914

Nope, didn't work. I've been able to add my account with full control to the install folder and everything inside, but nothing has changed, even opening the sqlite exe only gave the previous results.

>>8915

It sounds like we are on the right track. I guess your USB folder got created by another user or due to some unusual Windows flags the drive itself has some 'shared' status and so didn't inherit full user permissions in some way. I've had this shit before moving previously-network-shared folders from older Windows to new Windows, where the same user owner wasn't recognised and I had to do admin-level 'take ownership of this private folder' stuff.

I'm afraid I don't know enough about advanced Windows permissions stuff or your specific situation to offer much more help. I guess there is still some 'don't let this access this' flag somewhere, maybe in like the 'owner' of client.exe or the install folder? For now, it may be simpler to just turn off vacuum and forget about it. It'll probably magically fix itself the next time you update that USB hardware or your OS.

If you really want to get one good vacuum in, you can probably just copy the .db files and the sqlite3 exe to a new temp folder on your desktop and do the manual vacuum there and then copy them back.

>>8951

thanks for the help, it was appreciated :)