I’m sorry to begin by saying this but this is infuriating. A quick search about SeaDrive will tell you this has been a request since 2018, 6 years ago.
The current structure in SeaDrive is confusing, impractical and just bad. Not only does it needlessly use a “Shared with me”, “Shared with groups” structure, but it also includes the username in the absolute file path. This means that if you use Adobe Projects with linked resources (templates, images, etc) they break from user to user.
Let’s imagine this scenario:
I have a personal library called library1
Someone shared a library called images with me
The project manager shared a library called documents with a group
The admin shared a library with everyone which is called procedures
With a flat structure you open your seadrive root folder and you would have all those libraries right there. Clean and simple. With the current structure, you have to go (username)/(shared with X)/(the library) and as I said everything which uses absolute paths breaks.
The behaviour of the standard Seafile client supports this, but it doesn’t have smart/on-demand sync. And WebDav just doesn’t cut it if you have large files or a lot of files.
Aside from that Seafile is perfect. I’m currently using community edition but I would PAY for this.
You should notice from previous discussions that we had no plan to support two folder structures. This remains unchanged. Supporting two structures may be useful for some users. But for most users they don’t need to choose. The current structure has been there for quite long time and works for most users.
We don’t want to add more complexity and potential bugs into the software. Switching to another structure also requires deleting all placeholders or using a new sync root, which could be problematic in many cases.
Yes this is the main message I got when reading previous topics. Still, I maintain that this structure is overall very poorly designed and inconsistent. It arbitrarily splits the libraries between “my libraries”, “shared with me” and then it flattens all group-shared libraries in “shared with groups” instead of separating the groups. It’s not even consistent in that regard. And worst of all with the username in the file path this makes collaboration almost impossible using Seadrive, which is currently the only option to have Seafile’s on-demand sync.
In my opinion, Seadrive should work like Seafile client does, by letting the user choose where to sync each library and then making it on-demand. Synology Drive does it this way, but it doesn’t have the other features Seafile has (encrypted libraries mostly). NextCloud also uses a flat structure for its on-demand sync.
Again I’m not saying it to belittle Seafile and Seadrive. Those are great products, the best I’ve found. Nothing is as reliable and robust as Seafile while offering the features it does. This is why it bothers me that it doesn’t go the extra mile by just giving this little bit of freedom to have on-demand sync and a proper structure for collaboration.
I understood that this will probably never end up on your roadmap but it would be kind of you to at least discuss it among yourselves. There has been a significant amount of topics on the subject and I’m sure there’s merit in having a better structure for SeaDrive.
The current categories are consistent with what the users see in the web interface. So it’s not arbitrary. I admit that there is no further division by groups in the “Shared with groups” category. It would be more complex to implement that. And with this basic categories it can help in the case when the user has access to very large number of libraries. In such case, having all libraries in a flat structure would be messy.
In the initial design, one of the goals is to make SeaDrive easy to use and understand by most non-tech users. So we decide to not ask the users to manually “sync” a library. In practice we found that hard to understand for many non-tech users. That’s also how Dropbox is designed: all files are automatically synced in one place. The users don’t have to choose which library (or folder) to sync. Having the choice to place a library to anywhere is flexible feature for tech users, but an unnecessary complexity for non-tech users. That’s why we create placeholders for all libraries/files in the virtual drive. And since this user experience is so different from the sync client, we decided to release a separate client named SeaDrive.
I can understand your points. But every design comes with compromise.
Hello Jonathan, thank you for the detailed reply. I think I understand the design principles behind SeaDrive a bit better and your resistance to complexity and changes makes more sense in this context.
Regarding the dropbox analogy, as far as I know this is different from Seafile. Libraries in Seafile are, for all intents and purposes, root folders within other drive solutions. It’s true that Dropbox does not ask you which root folders you want to sync. But as far as I know, it does not create subfolders which do not exist within the actual file structure. If I have three root folders like “documents”, “images”, etc it justs puts them directly in the folder I choose. It’s the same thing for NextCloud and probably OwnCloud. I’ve never worked with OneDrive or Google Drive but I’d wager it’s similar, as this is in fact the standard way to do it.
The only solution I tried which creates subfolders like SeaDrive does is Proton Drive. I’ve seen many complaints about it online.
To get back to the original subject. Now that you have explained SeaDrive’s design principles more in-depth I understand that you do not really want to have multiple ways to use SeaDrive. Perhaps a better way to do it would be to augment the standard Seafile client to allow it to use a VFS (virtual file system) with on-demand sync, the way SeaDrive does? This could just be a checkbox (“use VFS”) or something like that when synchronizing a library.
I’m managing a nonprofit and for now Seafile’s community edition does the trick but this issue with Seadrive prevents us from using it as our only drive solution. Even if VFS for the normal seafile client was a paid feature, I would switch to it in a heartbeat and not use anything else.
Honestly I think that decoupling VFS/smart sync would really bring Seafile forward for more techy users or sysadmins who require both a standardized file path (for collaboration or whatever) and on-demand sync. In this case, the development effort would be greatly reduced because you could integrate Seadrive’s VFS “backend” in the Seafile client. Obviously this would still be a big feature. In my personal life I’m a lead dev and I know that features like this are never easy to properly implement. But, in my opinion, it is worth the effort, even from your point of view.
I really agree with the flat folder structure.
Furthermore, these “root folders” are not even localized, so my users have a mix of spanglish folders all over the place…
I think you’ve put your finger on what’s most frustrating about seafile, I haven’t found an equivalent for several years in reliability and synchronization speed with seadrive, but the lack of an advanced mode is problematic for taking the product to the next level in my opinion. On a personal note, for dev purposes I’m experiencing dependency problems due to the fact that “My Library” includes a space. I’ve changed the space to “My_Library” with a HEX editor in seadrive.exe, which seems to work, but it’s a bit of a fiddle.
