Handle paths with more than 143 chars on encrypted FS

The Issue

On Linux, using encryptFS on top of ext4 (or another FS), the maximum path limit is 143. The why can be found in that answer from one of encryptFS developer: What is the maximum allowed filename (and folder) size with eCryptfs?.

The resulting Python error when trying to synchronise such files is:

OSError: [Errno 36] Nom de fichier trop long: '...'
OSError: [Errno 36] Filename too long: '...'

Current Behavior

As this particular error is not yet handled, the synchronization will enter in the endless loop trying to sync the document.

Fix

First, we have to handle the exception to put the document in error.
Then, there is not much we can do here.

We are almost in the same scenario than when syncing long paths on Windows with 2 divergences:
1) Windows has a short path representation: using win32api.GetShortPathName(long_path). This let us sync the document.
2) BUT, that document is not viewable nor editable as Explorer cannot work with long paths.

So, on Windows, we sync the document but the user cannot do anything.

On GNU/Linux, we have the only choice to not sync the document. Same result.

Note

We are dealing with 143 here, but the maximum file name length on every Linux FS is 255. So handling the OSError 36 will automatically handle such files too.