What I mean by custom root is the ability to customize the root drive and folder SeaDrive uses.
For example my current path on Windows looks like this:
S:\seafile\John\My Libraries\…
At the moment I only have control over a limited part of that path. I can choose the drive letter. I can/have to choose the root folder - seafile. I can choose my name - I guess. I can’t change the “main” library containers - “My Libraries”, “Shared with all”, etc.
Now I generally don’t like paths being “forced” on me, but in this case it creates some real problems.
Here’s a non exhaustive list of problems:
First and foremost there is a whitespace in the path - My😟Libraries.
This can result in many hard to debug problems when using those paths in certain software.
Like Python, Rust, Blender and Nuke, just to name a few.
My name is part of the root. In my case that’s not that big of an issue. But I do have a special character in my last name. Having special characters like ö,ä,ü,etc. will almost certainly lead to problems.
The path I get will always be different to the path someone has who I’ve shared something with. That’s a recipe for long nights of debugging. Why is it working for me, but not for them?
And here are some workarounds I’ve tried:
Using Mountain Duck and WebDAV to see if I can choose a mount point.
I stopped trying as sync performance via the WebDAV protocol is terrible.
Using the subst command in Windows to mount a folder to a drive letter.
This works for some applications, but breaks Git and VSCode.
Unfortunately Git seems to break through the substitution and uses the real path.
Using the net use command in Windows to mount a folder as a Network Drive.
Again this works for some applications, but unfortunately has a big performance hit.
Especially the VSCode intelesense server seems to struggle a lot.
So now at the end of a long “workaround” day I would like to ask the big question: Is there a way to change the root path? And if not - Is that something to implement?
Here are some ideas how to implement, going from “basic” to "ideal. imho.
Remove the user name. Let each user choose a directory where their files should live.
And allow the admin to predefine the exact names for the four main library containers.
The names change already based on the language setting. So changing them manually shouldn’t be to hard? Result → S:\seafile\custom_name\my_library\…
Remove the user name and mount the four main library containers directly to a drive letter.
Same as before - allow the admin to define the names for the four main container folders. Result → X:\my_library\…
My ideal solution: Allow the user to mount one of the four main folders or any library directly to a drive letter. This would be ideal as regardless what kind of library it is, my own, one shared with me, or a global one, I can control the entire path. Result → X:\…
Thats it. Thank you for reading. And I hope you’ll consider my points.
I just switched from Nextcloud and am very happy. Just this one thing and its “perfect”.
Welcome to the Seafile Community Forum! Pleased to hear that you haven’t regretted your switch form NC yet
Before anyone elaborates on your questions, just a quick question here: You seem to be using SeaDrive 1.x. Any particular reason? Why don’t you use SeaDrive 2.x? This is relevant because SeaDrive 1 and SeaDrive 2 do not use the same technology and the way they integrate in the file system is different.
Thank you for the reply!
I’m pretty sure I am using the 2.x version of SeaDrive. I’ll double check as soon as I get back to my machine.
What made you think I’m using 1.x?
I’m a little confused.
Not sure if there is a misunderstanding, but I’m definitely using the 2.x version and SeaDrive uses my local drive as its root.
Edit: I’ve uploaded a screenshot of my version and folder path. But the screenshot doesn’t seem to show.
The version is 2.0.26 and the path to “My Library” is D:\Seafile\John\My Libraries.
Ah come on; windows been like this for … 30 years; they all can handle it… I write python for all my interactions with Seafile, and the naming scheme is never an issue.
I doubt it; if anything - you’ll be an early bug detector for utf-8 support. Who depends on ascii names anymore?
I do agree though, having a custom mount path would be excellent; but none of my OSX tools let me chose the mount point (except Rclone); they all appear to use a single path (different across them all) but consistent within the said program. I dunno on windows…
I share the frustration. Windows has been like this for ever, but the matter of fact is that a big pool of software still doesn’t support special characters and whitespaces.
I would love to only use tools and software that support the use of my name (and whitespaces), but I don’t have that level of control. And the tools I depend on aren’t some small niche tools either.
Some examples for context:
Microsofts VS Code and Visual Studio both don’t handle whitespaces in error messages correctly.
The impact is small, but annoying.
Imagemagick. A tool to transcode images will refuse to work with paths containing non ascii characters. I would love to use something different. But its a library many other tools rely on and they wont change, just because I can’t control my path.
ffmpeg. Same thing as Imagemagick. But it depends on the version used by the developers. Some tools who rely on ffmpeg work others fail. The only way I can make sure it always works is to have a clean path.
And then there are my niche tools. Sure they are niche, but all those tools add up. And all those small Scripts and Tools aren’t always written with compatibility in mind. So that’s why we have to be as compatible as possible.
So I get your point. The path we have right is valid and should work.
But in some cases it doesn’t. It might work in 99% of the time, but that’s not good enough.
And here’s why: That 1% where it doesn’t work, it generates an unproportioned amount of debug work.
First you’ll need to know its the path which is the problem. And then you’ll need to find or create a workaround. Or in the worst case need to change your stack.
And that is why I ask and hope that the Seafile developers might have or find a solution.
Because the easiest way for us to save ourselves from that 1% of painful debugging is simply to use clean and compatible paths.
Ever think about legally changing your name? Drop the non-ASCII chars and life quickly gets better.
Switch to Jet brains. They don’t have the history of Microsoft taking over and monopolizing markets on a global scale. plus Jet Brains are super giving to the OSS community.
Duh, Adobe all the way, they won’t install anything error generating and system bloating.
4.That’s blaspheme from ffmpeg, expected more from them. Suppose a banding everything but webrtc isn’t an option?
…
Honestly surprised you hadn’t thought of all these already….
</joking aside>
That does suck - hope you got a little laugh, I know fighting the framework/System is misery.
Best of luck.
Oh, I did have an honest idea - no joke have you tried to try to use symlink?
subst. Unfortunately the substituted path isn’t respected by Git. Also during my research I found multiple postings of people discouraging the use of subst. Apparently the support for it is patchy at best.
sym link. I tried juctions as well as a soft symlink. Unfortunately it has the same issues as subst. Git and apparently others don’t respect the link and use the real path.
net use. Creating a network drive from the local host address of one of my folders inside Seafile. That works in principle. Git and everything I’ve tested respect it, but it has dramatic performance implications. One example: Usually in VSCode the auto complete options appear near instantly. Using Seafile via net use has me waiting up to 10 seconds for each statement. That adds up quick.
Share and Mount. I assume this is the same as using the net use command. But I’m not that familiar with Windows Network Drives. But the issues are the same as with net use.
Mountain Duck. I used the Mountain Duck Client to map a local folder to a drive letter. Interestingly enough that works pretty good. The paths are being respected and at least my VS Code performance is acceptable. My only issue with this one is the strong feeling of “jankyness”. Mountain Duck introduces an additional sync, online only, cache, etc. system into the chain. Which to me seems like a bad idea. But I have no hard evidence yet that it is.
What I’m doing now:
I’m still looking for Windows alternatives to the subst command. It seems like something reliable should exist in this space. I hope.
I’m looking at alternatives to Seafile and Nextcloud. I know those two are big projects with years of great free and open-source work. Its very unlikely I’ll find something better hidden somewhere under a rock. Most likely I will end up splitting responsibilities. Having one pure Fileserver without any web interface. Some FTP server. Not sure yet. And in addition to that some small tool which allows me to share specific files to my clients via a pretty web interface.
Seafile is so close to what we need. If anyone has a good workaround or they consider opening up the path for configuration I’ll jump on it.
Do you suggest using it with Seafile or as an alternative?
Can Rclone use the protocol of Seafile?
Also - Is there a place where I can find information about the protocol Seafile/SeaDrive use.
I was trying to find an alternative client. With Nextcloud I used Mountain Duck. But I don’t know what protocol I should look for.
It’s not WebDAV and not FTP I believe? So what is it?
It would be to support your Seafile not replace. Rclone can take the seafile WebDAV or perhaps API and expose that back you as a file system; so it abstracts all the various providers Google drive, Seafile, OneSrive, etc. check it out: Rclone.org
Rclone is a command-line program to manage files on cloud storage. It is a feature-rich alternative to cloud vendors’ web storage interfaces. Over 40 cloud storage products support rclone including S3 object stores, business & consumer file storage services, as well as standard transfer protocols.
Thanks for the tip!
I’ve just tried rclone and it is working, but very slow.
Not sure if I can improve performance by changing something about the configuration, but right now its really slow. Maybe rclone uses WebDAV, but I disabled it on my Seafile server, so it shouldn’t !? .
I tried a few things in the past days, one of them was to run Seafile with an S3 Backend and connect directly to that S3 Backend via a Desktop Client. Unfortunately the only Client I got running was Mountain Duck and for some reason the performance is really bad. Creating files and uploading is super fast. But deleting and moving files is extremally slow. It’s moving/deleting 1-3 files per second (those are 1KB files).
Guess I’ll stick with the default filesystem Seafile for now.
Its still a bummer the drive paths are non-configurable, but at least it syncs fast.
Hopefully they allow for some modification some day🤞
On that note: I was wondering if there isn’t a simple way to edit the translation files of the drive client?
My biggest problem really is the whitespace in the “My Libraries” and that changes depending on the language. If we could add a “no whitespace” language, that could fix my problem. And should just be another language?
Cheers J
Edit: I tried to change the translation using the guide in the documentation, but that only works for the seahub web interface. I fear to change the drive client translation I would have to compile it myself. Thats a bit too custom for my taste .
Can someone from Seafile explain why SUBST should be avoided?
I mean if the SeaDrive client 2.x cache location is: c:\seadrive\cache
Then I can map any drive drive to any cache folder, for example: subst M: c:\seadrive\cache\myname\My Libraries
We are using Seadrive client 2.x this way and seems to be working. What is the “official” reason not to do it?
Thanks!
ps.:
We need this or some similar solution, namely to see files under a common path for all users. A lot of software we use simply don’t see Seadrive root in their File Loader window, only “traditional” windows drives. An additional problem that even if they could see it, the user name included in the root drive name “Seadrive (username)” . A lot of our documents we create references to other documents and the referenced file name saved in the particular document. But as the root path is different for every user (because the user name included in the root) there’s a reference not found erre when they open files created by other users.
I don’t think any Seafile Rep. will say anything against using subst.
They actually point to using using symlinks in a different thread:
The problem with subst is not with Seafile, but with support from other software. subst and symlinks for that matter don’t enforce their use. Any application has the ability,
to break through the substitution and access the real path. That’s the issue.
Example: Real Path → D:\Seafile\Tom\My Libraries\Project Substitution → subst X: D:\Seafile\Tom\My Libraries
When you access X:\Projects some apps will see and use D:\Seafile\Tom\My Libraries\Project instead.
I’m using subst a lot and in my experience it mostly works. The only instance that doesn’t is Git.
Unfortunately that makes subst a deal breaker for me. But maybe not for you.
Thanks for the answer. Actually we have been using SUBST on Seadrive 2.x folders for over a year now, and we think we don’t experience any issue connected to this. The tricky thing that we experience some issues (client sometimes goes out of sync and mess up the files on the server) but we couldn’t know for sure that it is related to the SUBSTed drive ot not - but we think it is not.
We don’t use Git (with Seadrive client), and all other software we use play nicely with SUBST.
I think by adding an option for an account should meet your needs: Users can choose the username in the path.
If your workflow depends on a fixed path for a library, the library should be shared in some group. So that it always appears in the “Shared with groups” folder. One exception is for the owner of the library. But I think you can use a special account to create such libraries. This account is not for a real user.
The “Shared with groups” folder still includes whitespaces.
And the name of that folder depends on the language setting of the user.
So this requires from us to train our users to choose the correct language.
Which is of course error prone.
But maybe this would be a “simple” solution for the problem:
Add an additional non-whitespace translation to the Seadrive Client
So “Shared with groups” would become “shared_with_groups”
And then allow the clouds admin to manage the language for every user.
I admit the second point is probably quite difficult, as the cloud config has no influence on the client side right?
But having point one would already allow for a correct path and now only the users need to be trained on picking the correct language.
Do you think that would be a realistic change for the dev team to make?
this really needs to be something addressed by seafile.
This one issue of having the user name in the sync or mapping basically means anything with a defined file path wont run so where user sharing comes in it breaks the ability to do this as the file paths wont work on things like scripts or photoshop files with linked assets.
Please remove the user from the seadrive directory or making optional, this is a huge thing!
I can choose the drive letter.
I can choose my name - I guess.
I can’t change the “main” library containers - “My Libraries”, “Shared with all”, etc.
Result → S:\seafile\custom_name\my_library\…
Result → X:\my_library\…
Result → X:\…
.