apparently there are just the 3 of us discussing this topic.
What I can contribute is what make sense from a user’s point of view.
For us, read-only is a feature that makes sense and must work 100% - I would actually have preferred not to have it at all than how it is implemented right now.
In our daily use, we have absolutely no extra feature that we need or any other topic that must be fixed - so from our point of view, this is the urgent task that needs to be fixed.
Nextcloud is a software that we don’t want to use for various reasons (performance mainly) - but at lest they have implemented read-only correctly and 100%.
On the other hand: Seafile has “something” but not working in all cases and causes just problems every day in our company.
We use currently just 9 users but would like to go up for 15 users and thus pay much more for the pro version… but I will hold back our investment until we have read-only properly working and tested.
For us, it’s not a minor thing - its a basic feature that should work
Maybe you can tell me what other things are so hi-prio?
I can wait, but someone from Seafile should tell a clear date when Read only will work.
Without that, I don’t want to pay more licenses
Hi Adrien,
I agree, read-only should work properly. It is the bread-and-butter business of sync solution. I also agree: your instructions provide guidance for the development.
What are other topics: Python 3 migration just one example. That affects all users - irrespective of the clients used. There are others.
I am in no way telling you that you are wrong. On the contrary. I am the first one that says: Stability/user experience goes before new features/extensions. Hence, I am thankful to you for your consistent nudging. Keep doing so!
The read-only function should just work. With Seadrive I also have mistakes everywhere. But I am confident that a resolution will be forthcoming. For me it is a basic function.
This post is dating from April 2019 and I am disappointed
Read only function is great but I still do not see a solution - it seems you are busy with maintenance (good) and adding fancy features (debatable)…
I just tested 7.0.13 and still it is not possible to solve the basic read only function
files deleted from a read only folder are not automatically synced back
adding files in a read only location does not show proper and easy to understand error message
(there is now a short time where the user sees a error - but just for the next sync - as soon as there is another sync from the client, the error message goes away and the folder seems to be perfectly in sync)
later
My subscription for the professional version must be renewed in April but I still have zero benefit except file search.
There is no other feature that I really need compared to the community version - so I start to ask myself what real benefit do I get for the pro edition?
Actually I would like to upgrade to 20 users per year, but only if we have a proper read only handing…
I like seafile - so please tell us that this will be fixed soon
Thanks
It’s actually very simple what the seafile client must do in a read only folder.
1.) if a user deletes a file, it is synced back
2.) if a user modifies a file, the original is also synced back and the modified must be renamed (conflict) - same as you have to do for other conflicts as well
3.) if a user places a new file (or creates a conflict file) in a read only folder, the error message must be 100% clear and only go away once the problem is solved
I think this is something that should be possible to implement.
And once again: I have explained in detail how it can work and even pointed you to the Nextcloud implementation and suggested to do it the same way…
You just have to find the time to see how the guys from Nextcloud did it, check if you agree and implement it.
I am still available to help you guys from a user perspective and I hold my credit card ready to upgrade our pro version to 20 users - but I must be sure this (imho) basic feature works
I understand and we are willing to make handling of read-only sync more perfect. But in my opinion the auto sync back of files is nice-to-have but not a must for everyone. So it’s certainly on our development plan but not so urgent. Recently our desktop development team is busy working on 2.0 version for SeaDrive, which include great improvement on Windows. We’ll have more time to work on the read-only sync in a month or so.
With regard to the error notification, there is an error in the file sync error dialog and the error sign in the system notification area won’t disappear until the user read the error in the dialog.
if it is read-only, the data synced to the user must behave as it is - “read only”
A sync back in absolutely necessary and not more complicated than any other sync that you do I guess.
for the error message: this is exactly the problem
if the user clicks on it, without correcting the problem, the error is not seen anymore.
This is not what should be implemented
If there is inconsistency in a read-only folder, the user must resolve the problem and only after that the error does go away.
Again and again: install Nextcloud and test it YOURSELF - you will see how it should be done more or less.
this is sad to hear
It would have been nice to know a year ago that you will not change it
Anyway: you’re pushing customers away to go for other solutions that handle this properly
I can not believe that all your customers are happy how you handle “read-only” which in fact is not (at least not for the sync client)
The only workaround I found is to tell all users to periodically “resync” ALL libraries in order to be shure that they have all files and no conflicts.
I have not found any other solution than this…
So basically I tell all users: don’t trust Seafile - you can not be 100% shure that you have all files unless you manually resync all libraries from time to time… great…
btw: once the users will correct the situation (resync, remove files in RO folders, sync again), they will still have the error in the “sync error log”… because it is a log file that we “abuse” to tell the user where to correct hings, the error persists for ever - confusing the user once more as he thinks that everything was corrected and the error should go away.
A log file is not the proper way to do this IMHO
I was really hoping there would be more users out there with the same problem
If anyone reading this and thinks we should make read-only sync better in Seafile, please post your thoughts here. That would be nice.
The word “reliable” (and its close cousins) is featured twice in this teaser on Seafile’s home page.
Given Seafile’s commitment to reliability, the number of users requiring sync-back and conflict handling messages should be a second order priority. The all dominant question must be: Is the current operation ensuring reliability? My take is: It is not or, a little softer, Seafile could do better.
This said, I think @adrianriedo and @Jonathan are not so far apart. When reading Jonathan’s post, it seems to me that there will be improvements forthcoming.
It seems to me that only the “right-in-your-face-you-must-solve-this-conflict” message (as demanded by @adrianriedo) is something that Seafile will not implement. I can live with that.
thanks @rdb for your support
after many years of CE user and now 1 year PRO user I must say that sadly there is not really a difference.
I was actually hoping to get better support as PRO user and that this community of PRO users is more vibrant… I conclude that most time on seafile backend was spent on migrating the codebase to new libraries, etc whereas basic functionality and reliability IMHO did not advance.
We still use the latest v6 in our productive environment - we also have a v7 install but there is absolutely no benefit in terms of file sync and reliability that would make us move to v7.
Summary: 1 year down the road and we are still on v6 and see no reason why to upgrade.
My question: was the time wisely spent?
Challenge my statement and tell me what I’ve missed…
PS: as CE user we thought that we missed file search and file locking.
After 1 year: no we actually don’t really miss it, we could move back to CE
But PRO should also mean that our voices are heard so I kept on believing…
We started with 9 users (just 100.-) but wanted to go to 20 users (960.-) per year.
I would actually pay for a proper sync client that can do read only.
I think I better save the 960.- per year and move back to CE and shut up.
…or I can take that money to the big players but that’s not cool
I am wondering where the paying customers for Seafile are and if they are all happy…
PPS: I know many users in Switzerland (even ISP’s) that use and offer Seafile
But I know zero that are actually paying for it… all CE users
I’m drifting off the main topic, but it might help move forward:
what if you listen to your PRO users and drop read only for CE and make it a PRO feature?
I think you get the point:
from our perspective I see 2 choices:
be an engaged PRO user and demand proper implementation
be a CE user and shut up
This brings me to another conclusion:
maybe there are not as many PRO users as I thought and most time from the Seafile team was spent to make everybody (mainly CE) happy?
First, why would you hear of other pro customers? They most likely communicate via email.
Second, why do you expect some special treatment for just 100 a year? Even for 960 a year wouldn’t be something where I expect anything more than the product and some help in case there are issues or questions (which by far doesn’t mean implementation changes on request).
You get the search, online garbage collection, possibility to use object storage and multiple storage backends and some other advanced features.
With regards to the desktop client synchronization I wasn’t able to find a better performing product (although I admit that there still could be some improvements).
And with regards to new features I hope they’ll only release thought through and well working features. When adding every feature someone asks for the whole product will be a nightmare in the end. From a technical point of view as well as from a users perspective.
Maintaining the code base is an absolute requirement to have a reliable and maintainable product in the long term and and upgrade to python 3 is urgent because support for python 2 ended.
The markdown editor was a waste of time imho.
SeaDrive is a great idea and when SeaDrive 2.0 works well it is a huge step forward offering new use cases. The first version is nothing more than a prototype, though. And although it might seem to be easy I think such a client is a HUGE technical challenge requiring lots of effort.
@shoeper thanks - great to see that the people start writing in this thread
Yes, my statement is harsh. The fact that Seafile only after 1 year say that the will not implement sync back for read-only was “upsetting”. IMHO this is what “read-only” should be, no?
PRO: whenever I’ve sent an eMail in the past to Seafile, it was not replied or if, then very late.
So I started to use this forum
Yes, we are a very small customer, but a customer after all (one that is hoping to make the product better)
That’s also a commitment.
Python 3: I get the point, and I agree
Desktop Client: I agree, it is a great product and I’ve stated that many times.
What is upsetting is the fact that read-only feature is available, but not fully supported by the Client.
The caveats must be discovered by the user.
In summary I hope Seafile changes the mind and will find time to implement read-only with the Sync Client properly. My suggestions, tests with competitor products, explaining what we as user are expecting are all in this thread.
It is up to Seafile to implement it or not - currently it is a “no”
The only way to change their mind, is that other users will post here also that they want it.
So coming back to why post here and not use eMail:
It is the only way I see to find other users with the same request and hope to get it working.
After all, this forum should not only be about users finding bugs and reporting to Seafile.
It should also be a platform for Seafile to listen to users - I could not imagine a better way to make the product better and I still did not give up hope.
I agree that this is an issue that should be worked on. Unfortunately its not the only point.
Ok, that’s actually bad.
It is one of the features that was added fast after some customer requested it (as far as I recall). As we see the obvious thing happened and it doesn’t work well.
I reiterate what I said before: I support sync-back wholeheartedly and I agree it should have been implemented before with read-only sync. But railing at the developers when the process of prioritizing development tasks does not yield the anticipated results is counterproductive and it does not take account of the dynamic nature of the development process.
Maybe @Jonathan can shed a little more light on the timeline. Recall, he said:
In my opinion, there is distinction between being reliable and being perfect. Reliability is a must for Seafile. Whether do we make a function perfect depends on how much efforts it will take and how frequently users will meet this case.
With regard to your requirements:
Auto sync back of deleted file in read-only library: Seafile will not delete the file on the server. So it matches the basic semantics for “read-only”. And it doesn’t cause data lost since file is not deleted on the server. So it’s “reliable”. In case the user changes the file and then deletes it, the user will receive notification when he/she changes the file. You may say the user may update a file and then delete it quickly. I don’t think this happen a lot. So we think this is not a reliability issue but just a perfection requirement.
Update of a read-only file: The client will notify the user and keep a “log” in the file sync error dialog. The “log” will not disappear unless the user delete it (new in 7.0.6). The purpose of this message is to “warn” the user their changes are not saved to the server. The only reasonable action a user can do is to copy the file out of this folder. Once this is done, the user shouldn’t be frightened by the warning left in the file sync error dialog. This is similar to the case of deletion: the purpose should be to warn the user about the read-only property of this folder. Actually we took your suggestion to warn the user in such case since it may cause data lost otherwise.
In terms of complexity introduced by perfecting these two requirements:
Auto sync back of deleted file in read-only library: we need to modify a now very stable syncing procedure to do extra checking and download a file. The work is not so simple as you thought. And it may introduce new bugs. Given that the current situation is not harming data reliability and not so many users think it’s a real pain, we give it low priority.
Update of a read-only file: Checking errors automatically to see whether they still exist is also not easy to be done robustly. There will be many edge cases that a false detection can be made. On the other hand we think it introduce unnecessary complexity into the code. So we prefer to avoid it.
Dear @Jonathan
thanks for taking time to explain your thoughts on this and possible plan
From an engineering point of view, I understand your situation
From a commercial point of view, you are facing a market where other solutions exist and compete.
It is absolutely your right to say, “we don’t do what others do” (e.g. Nextcloud, etc), but sooner or later customers who want read-only will look for alternatives. I just give you honest feedback from a user and market perspective.
So from a commercial point of view: did you ever install and test how Nextcloud handles read-only?
-> what is your opinion on their implementation of read-only?
