SeaDrive for Linux/Mac cannot access files, created by Windows clients, having accented characters in their names

  • Environment:
  • Server: Professional Edition v. 7.1.6
  • Client: SeaDrive v. 2.0.13
  • Platform: Mostly Windows, but also Mac and Linux

A shared library has files with some (normal) accented characters in their filenames.

These files have been created by windows clients (not sure if Seafile sync client of SeaDrive for Windows).

OSX and Linux users with SeaDrive 2.0.13 cannot access them.

As an example, a simple find (linux) in a shared library gives out these errors:

find: ‘SeaDrive/Shared with groups/XXX/Storico/Progetti Nazionali/YYY/POC2019/RRR/Mod. 02 - Scheda di visibilità 2019.pdf’: No such file or directory find: ‘SeaDrive/Shared with groups/XXX/Storico/Progetti Nazionali/YYY/POC2019/RRR/Mod. 02 - Scheda di visibilità 2019.docx’: No such file or directory 

The OS X finder does not display them at all.

A (newly installed) SeaDrive on a Windows PC can access them without any problems.

No problems at all via web interface, nor with Seafile sync client on Linux or OSX.

Is this file shown on OSX and Linux? Do you check both command line and GUI file manager (e.g. Finder)? Do you see related logs in seadrive.log when you list the folder that contains this file?

Yes, we tried. Depends on the “client” app.
Finder just ignores the files and does not display them.
Command line (ls or find) return error as reported above.
In Sunflower under Linux I can see the file with 0 bytes and cannot open it. In Nautilus I cannot see it.
Nothing in the logs about this.

We cannot reproduce the same issue with the file name you provided. Do you have this problem for all files with accented characters in the name? What happen if you use cat command to get the contents for this file? What if you remove this file from the library and upload it again?

  • cat (on Linux): same No such file or directory error of find (as expected)

  • on a Windows box with SeaDrive 2.0.13:

    1. the troubled file can be read1. (double click) fine

    2. the file is copied locally (C:) then copied back to SeaDrive: from Linux the file is still in error
      However I can see that SeaDrive in Windows has the “spinning arrows” (synching) status in Explorer!
      The file history is still completely blank! The SeaDrive log states:
      .
      [04/16/21 09:58:52] Repo 'XXX' sync state transition from 'synchronized' to 'committing'.
      [04/16/21 09:58:52] All events are processed for repo bafdcd74-1f0d-4c59-8346-7704e75b5409.
      [04/16/21 09:58:52] Repo 'XXX' sync state transition from 'committing' to 'synchronized'.

    3. I then remove the file with windows explorer on the same machine. The file appears gone, the log states:
      .
      [04/16/21 10:03:07] Repo 'XXX' sync state transition from 'synchronized' to 'committing'.
      [04/16/21 10:03:07] All events are processed for repo bafdcd74-1f0d-4c59-8346-7704e75b5409.
      [04/16/21 10:03:08] Repo 'XXX' sync state transition from 'committing' to 'uploading'.
      [04/16/21 10:03:08] Upload with HTTP sync protocol version 2.
      [04/16/21 10:03:08] Transfer repo 'bafdcd74': ('normal', 'init') --> ('normal', 'check')
      [04/16/21 10:03:08] Transfer repo 'bafdcd74': ('normal', 'check') --> ('normal', 'commit')
      [04/16/21 10:03:08] Transfer repo 'bafdcd74': ('normal', 'commit') --> ('normal', 'fs')
      [04/16/21 10:03:08] Transfer repo 'bafdcd74': ('normal', 'fs') --> ('normal', 'data')
      [04/16/21 10:03:08] Transfer repo 'bafdcd74': ('normal', 'data') --> ('normal', 'update-branch')
      [04/16/21 10:03:08] Transfer repo 'bafdcd74': ('normal', 'update-branch') --> ('finished', 'finished')
      [04/16/21 10:03:08] removing blocks for repo bafdcd74-1f0d-4c59-8346-7704e75b5409
      [04/16/21 10:03:08] Repo 'XXX' sync state transition from 'uploading' to 'get sync info'.
      [04/16/21 10:03:09] Repo 'XXX' sync state transition from 'get sync info' to 'synchronized'.
      .
      The web interface reflects this status.
      Then, still on windows, I copy back the local copy of the file into the folder. It’s being uploaded.
      Now I can see it both in SeaDrive and web. Its history is consistent (my name along its creation log, with the correct date - now). However its “last update” in the web interface still states “a year ago”
      .
      Trying to access the file with SeaDrive under Linux. No way, the file is still unreadable. Here the log states that the XXX library has been updated (synchronised status)

    4. I then try to upload the same file using the web interface. It asks me confirmation about the file replacement. I confirm and… “Internal Server Error” message. Retry, done!
      However… I see it duplicated both in the web interface and in SeaDrive for Windows:

      and in Linux!:

      both files are now readable from both platforms.
      .
      Now I delete the newer file in windows… and the file gets unreadable again under Linux (same original situation).
      Re-upload from web, Internal Server Error again, Retry, two files again.
      Now I delete the older file. Bingo, the remaining file is now readable fine on all platforms.

  • OK, let’s try to do it in a different way. I pick another file with the same problem. Now, under SeaDrive Windows, I try to rename it.

    1. shift+F2 on the file, in explorer. I get:
    2. I then move the cursor just after the à character and press the backspace (delete) key on my keyboard. I get:
    3. press enter… voit-là, now the problem is fixed!

    So, it looks like the à was not a simple accented character…
    In fact, if I “edit” the original filename and paste it into VIM for windows, I can see: Mod. 02 - Scheda di visibilita` 2019.pdf even if in Explorer (etc.) I can read Mod. 02 - Scheda di visibilità 2019.pdf
    Command prompt, however, can display it as it really is!

That said, I assume the problem is NOT with simple accented characters but with some strange unicoded filename…
Do you have evidence of problems in SeaDrive with this kind of names?
I can maybe provide such a file for your tests if this could help you.

Hi @Ivan_Andrian

Thank you for the detailed report. Unfortunately I cannot see the pictures. It would be helpful if you can send some test files to us.

Hi @Ivan_Andrian

Thank you for sharing the files. However I cannot reproduce the same issue with the files you provided. I uploaded the file from both Windows SeaDrive and web interface. The file can be successfully opened on Mac and Linux. Also when I try to rename the file on Windows, I didn’t have the issue you mentioned.

Perhaps it’s some encoding issue of the Windows machine you use?

The tests has been made with a standard Windows 10 pro. Windows is famous for its difference between character encoding between western and eastern versions, but I cannot say more than that.

I’ve tried to:

  1. unzip the ZIP file I sent you on the desktop (same windows machine), then copy the files on a different seafile library, using seadrive 2.0.13.
  2. access them from linux (seadrive 2.0.11):

SeaDriveTests$ ll
ls: cannot access ‘Mod. 02 - Scheda di visibilità 2019.pdf’: No such file or directory
ls: cannot access ‘Mod. 02 - Scheda di visibilità 2019.docx’: No such file or directory
ls: cannot access ‘Mod. 02 - Scheda di visibilità 2019.zip’: No such file or directory
total 0
??? ? ? ? ? ? ‘Mod. 02 - Scheda di visibilità 2019.docx’
??? ? ? ? ? ? ‘Mod. 02 - Scheda di visibilità 2019.pdf’
??? ? ? ? ? ? ‘Mod. 02 - Scheda di visibilità 2019.zip’

I suspect that if I unzip the file under linux same character conversion is performed:

$ unzip ‘Mod. 02 - Scheda di visibilità 2019.zip’
Archive: …/VirtualBox VMs/SharedFolder/Mod. 02 - Scheda di visibilità 2019.zip
Mod. 02 - Scheda di visibilità 2019.docx: mismatching “local” filename (Mod. 02 - Scheda di visibilita╠А 2019.docx),
continuing with “central” filename version
inflating: ./Mod. 02 - Scheda di visibilità 2019.docx
Mod. 02 - Scheda di visibilità 2019.pdf: mismatching “local” filename (Mod. 02 - Scheda di visibilita╠А 2019.pdf),
continuing with “central” filename version
inflating: ./Mod. 02 - Scheda di visibilità 2019.pdf