nautilus/nemo shell integration causes python AttributeErrors

[jnweiger]

while testing 2.4.4 rc1, this is seen on stdout of nemo:

Traceback (most recent call last):
  File "/usr/share/nemo-python/extensions/syncstate-testpilotcloud.py", line 217, in get_file_items
    state_ok = state.startswith('OK')
AttributeError: 'NoneType' object has no attribute 'startswith'

seems to happen during resync, when non-ascii characters are present in file names.

[jnweiger]

Same error seen wiht nautilus extension:

Traceback (most recent call last):
  File "/usr/share/nautilus-python/extensions/syncstate-testpilotcloud.py", line 217, in get_file_items
    state_ok = state.startswith('OK')
AttributeError: 'NoneType' object has no attribute 'startswith'

[michaelstingl]

@ckamm @ogoffart Is there an easy way to improve here?

[guruz]

Is your python python2 or python3?
Do you have the filename too? Feel free to obsofuscate, just the non-ASCII is important I guess

[guruz]

How does it look UI wise in nemo?
No overlays shown at all?
Any horrible error dialog popping up?

[guruz]

Linking #6406 (comment) #6393

[ogoffart]

Is this a regression from 2.4.1? Is the problem still here in 2.5? (I was not able to reproduce the problem in 2.5)

[jnweiger]

Oh, I forgot to mention the good side: overlay icons are doing fine. No errors showing on the UI.

[jnweiger]

nemo says: Using python version sys.version_info(major=2, minor=7, micro=15, releaselevel='candidate', serial=1)

Example files should be

echo hello > 'äöü.txt'
mkdir Jü
cd Jü/
vi xxx
 ...

but the issue does not trigger today. Sorry.

[ckamm]

I didn't dig deep enough to see why this would happen, but it seems some codepaths assign None to 'state'. The above PR simply guards against this case and should be fine regardless of the source of the problem.

[guruz]

Oh, I forgot to mention the good side: overlay icons are doing fine. No errors showing on the UI.

@ckamm @ogoffart do you agree that this doesnt warrant a new rc?
Either we take rc1=final or we take this patch in without doing a rc2 and have HEAD=final?

[ogoffart]

Yes, this is probably not a regression, and it has not so bad side effect. So it does not need to be in 2.4.2

[ckamm]

I agree, no new RC necessary, rc1 can be final

[guruz]

@jnweiger do you still get this with 2.5.0 beta1?

[jnweiger]

linux mint tara

testpilotcloud version 2.5.0daily20180808 (build 10016)

Reproducing the issue with
echo huhu > Documents/äöü
now shows a different error.
This error happens when user clicks on the file named 'äöü' and also during a sync run.
As soon as this error appears, the overlay icons are no longer show on the 'äöü' file.

$ nautilus
sys:1: PyGIWarning: Nautilus was imported without specifying a version first. Use gi.require_version('Nautilus', '3.0') before import to ensure that the right version gets loaded.
Initializing testpilotcloud-client-nautilus extension
Using python version sys.version_info(major=2, minor=7, micro=15, releaselevel='candidate', serial=1)
Traceback (most recent call last):
  File "/usr/share/nautilus-python/extensions/syncstate-testpilotcloud.py", line 229, in get_file_items
    return self.ask_for_menu_items(files)
  File "/usr/share/nautilus-python/extensions/syncstate-testpilotcloud.py", line 236, in ask_for_menu_items
    socketConnect.sendCommand('GET_MENU_ITEMS:{}\n'.format(filesstring))
UnicodeEncodeError: 'ascii' codec can't encode characters in position 37-39: ordinal not in range(128)

OK: the original issue is fixed.

BAD:We got past the NoneType just to find the next snakepit with illegal ascii encoding...

[jnweiger]

linux mint tara

owncloud client 251rc2

Reproducing the issue with
echo huhu > Documents/äöü

No more encoding errorsare shown on nautilus stdout/stderr, when clicking the file or opening its right click menu.

-> PASS

Double click on a) a file without suffix, or b) a *.txt file produces other strange messages, but that is a different issue #6865