/hydrus/ - Hydrus Network

I may have updated from some ancient release to v239 and now I am getting a "Fatal Error! Failed to execute pyi_rth_win32comgenpy" on startup and it won't run. Pic related. How fucked am I?

>>4856

Thanks for adding the ordered paths and improving import speed. It is much comfier to use now.

I have a noticed a few bugs with file services.

When I try to commit new files to a file repository I get the following error:

AttributeError
'module' object has no attribute 'WSAEACCES'
Traceback (most recent call last):
  File "/opt/hydrus/include/HydrusThreading.py", line 276, in run
    callable( *args, **kwargs )
  File "/opt/hydrus/include/ClientGUI.py", line 2468, in _THREADUploadPending
    service.Request( HC.POST, 'file', { 'file' : file } )
  File "/opt/hydrus/include/ClientData.py", line 1772, in Request
    ( response, size_of_response, response_headers, cookies ) = HydrusGlobals.client_controller.DoHTTP( method, url, request_headers, body, report_hooks = report_hooks, temp_path = temp_path, hydrus_network = True )
  File "/opt/hydrus/include/ClientController.py", line 389, in DoHTTP
    def DoHTTP( self, *args, **kwargs ): return self._http.Request( *args, **kwargs )
  File "/opt/hydrus/include/ClientNetworking.py", line 347, in Request
    ( response, size_of_response, response_headers, cookies ) = self._DoRequest( method, location, path, query, request_headers, body, follow_redirects = follow_redirects, report_hooks = report_hooks, temp_path = temp_path, hydrus_network = hydrus_network )
  File "/opt/hydrus/include/ClientNetworking.py", line 273, in _DoRequest
    ( parsed_response, redirect_info, size_of_response, response_headers, cookies ) = connection.Request( method, path_and_query, request_headers, body, report_hooks = report_hooks, temp_path = temp_path )
  File "/opt/hydrus/include/ClientNetworking.py", line 900, in Request
    ( response, parsed_response, size_of_response ) = self._SendRequestGetResponse( method, path_and_query, request_headers, body, report_hooks = report_hooks, temp_path = temp_path )
  File "/opt/hydrus/include/ClientNetworking.py", line 529, in _SendRequestGetResponse
    ( response, attempt_number ) = self._GetInitialResponse( method, path_and_query, request_headers, body, attempt_number = attempt_number )
  File "/opt/hydrus/include/ClientNetworking.py", line 589, in _GetInitialResponse
    if e.errno == errno.WSAEACCES:
AttributeError: 'module' object has no attribute 'WSAEACCES'

It seems to affect only new uploads since I have no problem to add & sync new repository or petition existing files.

It starts working if I press the 'refresh account' button in 'review services' window or if I commit petitions for some files first. This looks like a new bug in v239.

There are also some errors with file permissions when removing remote file / tag repository:

2017/01/06 18:46:27: Trying to delete /media/hydrus/client_updates/53f4148070f4ae16e2786da0ba33e9548ee3d8044209b10bff053bd0b00001bd caused the following error:
2017/01/06 18:46:27: Exception:
2017/01/06 18:46:27: OSError
[Errno 13] Prístup odmietnutý: '/media/hydrus/client_updates/53f4148070f4ae16e2786da0ba33e9548ee3d8044209b10bff053bd0b00001bd/1483621632_metadata.json'
Traceback (most recent call last):
  File "/opt/hydrus/include/HydrusPaths.py", line 193, in DeletePath
    shutil.rmtree( path )
  File "/usr/lib/python2.7/shutil.py", line 252, in rmtree
    onerror(os.remove, fullname, sys.exc_info())
  File "/usr/lib/python2.7/shutil.py", line 250, in rmtree
    os.remove(fullname)
OSError: [Errno 13] Prístup odmietnutý: '/media/hydrus/client_updates/53f4148070f4ae16e2786da0ba33e9548ee3d8044209b10bff053bd0b00001bd/1483621632_metadata.json'

2017/01/06 18:46:27: /opt/hydrus/include/ClientGUICommon.py:3810: UnicodeWarning: Unicode unequal comparison failed to convert both arguments to Unicode - interpreting them as being unequal
  if self._tb_text.GetLabelText() != text:

It probably removes the access permission (x) for the directory somewhere in the code. It also affects v238 so it's probably an older bug.

Speaking of file permissions the new https public/private keys generated by server have very generous file permissions in Linux which could potentially allow read access to any user of that system. Not exactly a good thing in multi-user environment. It is good practice to set the permissions to 400 to allow read-only access only to the file owner. Ssh for example completely ignores private keys with too open permissions.

System: Arch Linux, x86_64, using AUR package

>>4886

Other than the colours in file->options->colours, I pull everything from system defaults. Adding a night mode to automatically shade everything or similar is on my todo list, although you may have more luck in the meantime with an OS-level night-mode that hydrus can inherit from, or even something like f.lux that might do it better without my intervention.

>>4888

>>4890

>>4892

Great. You hit the 32->64bit changeover I did I think around v186. The solution then was to do a clean install just as you figured out. As all releases are 64bit now, I don't expect any more so traumatic updates in the future.

>>4891

The github is a mirror of my home work environment, so my workflow doesn't really support sucking code back from it. I'm happy to make very similar changes on my end to make packaging an app easier, though–can you describe exactly what USERDATA_DIR and LICENSE_DIR represent, so I can double-check my new db_dir stuff and whatever else doesn't mess any of this up for you?

>>4895

Thanks for this. I get similar, on any nested menu, but only sometimes. This bug is coming from an area of code I don't think I have control over. As it doesn't always happen, I suspect it may be an afteraffect caused by the other longstanding menu id overflow bug. I am slowly replacing all that bad menu code, so I'm going to see if this menuDepth > 0 one goes away with that.

>>4904

Thank you for these detailed reports. I will check this stuff today and update the permissions issue.

>>4905

This happens from time to time. It is often upnpc_win32.exe throwing the false positive–which I use to do UPnP stuff at the user's request–but I'd be interested to know if you get anything different.

>>4909

𝕯𝖊𝖚𝖘 𝖛𝖚𝖑𝖙, 𝖔𝖕𝖚𝖘

>>4910

re: colors, in the end I did go with an OS-level custom styling, which looks fantastic.

Thank you again

>>4939

I've made a similar change as your pull request for tomorrow's release. There's now LICENSE_PATH as you suggested and I've made a single DEFAULT_DB_DR, which is base_dir/db (i.e. install_path/db). If you want to change where a fresh client writes its stuff by default, you can set DEFAULT_DB_DIR to something like os.path.expanduser( '~/.hydrus_network' ), and I think you'll get what you want. Hydrus will try to create the directory if it doesn't exist. LICENSE_PATH is install_dir/license.txt by default. Let me know if I messed it up or misunderstood what you wanted to do here.

I haven't made all the changes you did as the other stuff needs to refer to the install path explicitly. Some of it is the update code that converts from the old fixed-under-install_dir system to the new one that can run the db from anywhere.

Note also there is the -d launch parameter. You could create a shortcut in your package that goes:

./client -d "muh_db_path"

And it'll also work.