Error concerning unsupported Windows filesystem symbols on Linux

[bertvandepoel]

After updating my Ubuntu 18.04 installation last night, presumably including a new Seafile client, I've noticed today that whenever I start up the Seafile client, I receive a very large amount of errors to notify I've used symbols in folder and filenames that aren't supported on Windows. I can see why this error is relevant to those who want to support multiplatform syncing, and why it would be enabled by default. However, since I don't use Windows (I stopped using Windows around 2008, I hardly know how to use Windows 7, let alone Windows 10), and many users of Seafile are Linux users who self-host an instance, it would be nice if we could somehow disable this error. For many, it doesn't matter that their filename for example contains a question mark or colon.

Beyond the notifications themselves, there's also the fact that all libraries containing a file that causes a notification is also shown with an exclamation mark on the client itself with an error. This made it seem to me that Seafile would not be willing to sync anymore, but a test revealed that as soon as I sync something, I get a green cloud again and everything seems fine.

I would therefore suggest that an extra setting is added to Seafile, for example under "Advanced" to disable this specific check for Windows compatibility. Furthermore, it might be relevant to consider if an error like this should cause the red exclamation mark next to the libraries even though syncing does not seem to be disabled by this err.r

I'm aware this is a duplicate of #1359 , but since that issue vented a significant amount of frustration (which I understand), it seemed relevant for me to file a more neutral issue.

[ep12]

And yet another duplicate: #1362.

I think it would be sufficient to add an early return here if the config option that is to be added isn't enabled, something like

if (!config_care_about_windows_compatibility) goto out;

Apart from that one-liner I have no clue how to add a config option., otherwise I'd create a pr... I'd really like to see a quick fix very soon, so maybe one of the maintainers can fix this...

[bertvandepoel]

@ep12 pretty sure the config options live in settings-mgr.cpp (https://github.com/haiwen/seafile-client/blob/master/src/settings-mgr.cpp), or at least the logic of it. Not sure if that's enough for you to be able to write a PR. I sadly don't know enough C++ to trust myself with this code, but I may be able to do testing if necessary.

[ep12]

Apart from playing around with an arduino and some minor other things, I've never written production C++ code... If it was python I'd be more confident... I had a look at it and it seems that (seafile-client) settings-mgr.cpp, ui/settings-dialog.ui, ui/settings-dialog.cpp and at some point the translations would need to be updated at least. For seafile it is at least daemon/sync-mgr.c, daemon/repo-mgr.c and daemon/seafile-config.c. I don't know how introducing a new config option is achieved in the sense that the client might try to get the value of an option before it is set in the user config files for the first time. At least that's where I'd expect things to break without in-depth knowledge about how everything is implemented. I think it'd be waaay easier for the devs to introduce that option (also: faster). I already said where the config value would be likely to be used, but sadly that's pretty much all I can contribute for now...

[bertvandepoel]

See https://github.com/haiwen/seafile/issues/2451#issuecomment-851837162 for some good news!