WebDav file locking to prevent overwrites #1308
Comments
|
also interested in some solution around this, but client would be happy for it to be a plugin/manual checkout method like https://apps.owncloud.com/content/show.php/Workin2gether+(Lock+files+in+WebUI)?content=164016 |
This comment has been minimized.
This comment has been minimized.
|
Quite frankly I think the idea got ditched because of the integration with Collabora Online... Although it seems a bit overkill to set up a Collabora Online environment just for this purpose... :) |
|
Well, if installing Collabora Online means we get sync client file locks (and web client) we'd install it even if the client would never use it... |
|
the problem is, that then the xls and co will beopen by libreoffice. this is no possibility for me. any news? |
|
Recently migrated from ownCloud 7 (file-locking worked fine) to a new server with ownCloud 9.1.4. File-locking doesn't work any longer but I decided to upgraded to Nextcloud with the Nextcloud installer to the latest version (12). Very easy to do but the file-locking still broken. This is a must have "feature" like @klm46 posted on 10 April for businesses and a big deal breaker for continued use of Nextcloud for us. |
|
The Workin2gether app is now released for NC12: https://apps.nextcloud.com/apps/workin2gether - might be just what you need |
|
@putt1ck does that work for webdav though? |
|
@grayum not to my knowledge, but it also doesn't work for email attachments, USB sticks, Dropbox, WeTransfer, GDrive and all the other ways people move files around when we wish they wouldn't. Locks via webdav (et al) also won't work if someone is editing a document offline - some things are best dealt with through policies and working practices. One client introducing NC has introduced policy of "sync only things you might work on near time or only want for reference" and then mandate users collaborating on files to visit the web interface to lock files with the aforementioned app before they start to edit them. |
|
@putt1ck I think we're getting a bit off topic. In my case (and probably most of the participants here) the customer uses webdav exclusively (via a networkmap). So files are only available online. The app you suggest involves users to use the webinterface of NC/OC and while this might work it's not very user friendly. And unrelated to the original post/request by @watermark. I do thank you for the suggestion though. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
Shouldn't this be easy to fix? Just allow syncing of the .~lock.documentname.odt files, and we are done! Or is there a way to manually allow for syncing of the .~lock files? Btw, I understand the problem that users can work on their files offline, and in this case a lock would have no effect. In practice, people are online, so in most of the cases the lock will be effective. If they worked offline and later sync, the file should be uploaded with an corresponding name, e.g. filename-conflicted_copy_2017-05-03--12-34.odt Thank you. |
This comment has been minimized.
This comment has been minimized.
|
Same here, also customers who need this feature to avoid overwrites. MAnual locking via the webinterface is not a realistic solution IMHO. Bit of a shame that this isn't implemented, want to avoid having to install a samba access just for thus ;( |
|
The Workin2gether app does sound like a bit of a workaround, frankly. Most of our users use the NextCloud sync client or WebDAV to access their files. One organisation has been querying options file locking for a while, at this point we have to tell them that it's not possible. Collabora Office is good, but it is a lot of code for the browser to execute and in our experience it doesn't work so well with really big spreadsheets or word processing documents. I see the lack of WebDAV file locking support as a current major limitation and missing feature. My employer would probably be happy to collaborate in writing and testing code to implement this feature, though it would probably make sense for someone more familiar with the NextCloud code base to work on it. |
|
How do you file lock something you're not connected to? |
|
Hi @putt1ck, if a person is using the NextCloud sync client and is offline, then of course they will just be opening up a file on their local computer and there will be no way to lock that file via the server. But quite a lot of file editing, in my experience, happens via the sync client with an internet connection. |
|
I can only see one scenario (people all accessing files via webdav) where automated file locking will add value - but in all other scenarios it doesn't add value and potentially lulls people into a false sense of security "this file isn't auto-locked so must be ok to edit". Where automated file locking is a useful feature, in a legacy "shared drive" scenario, it is because that is how people access files for editing. It is already breaking down because of people working around the limitations of shared drives, by using dropbox, email, Gdrive, to grab a copy of a file to work on it at home, on the train etc., and then having version conflicts when they bring it back inside the LAN. A document management system amplifies this by making it easier to have a local copy; In some DMSes, they differentiate between a download and a "check out", where the latter results in the file being locked; but this tends to breakdown anyway, because the download process is easier (doesn't require providing a reason) and is a more immediately obvious way to get the file. Right now the only broadly useful tech solution to collaboration I can see is something that can be set remotely to communicate to other users that a file is being edited. Automated file locking can only work for those opening files over webdav connections; every other access method requires a conscious "lock" trigger. Of course in teams with great communication a tech solution isn't needed... |
|
Hey everyone, sorry I have asked this before but did not receive a response, I'll try again: Is there a way to manually allow for syncing of the .~lock files? ...cause that would be a work-around that would help my use-case a lot.
I think what makes an application great is when even huge teams with mediocre communication can use it without messing their files up. I believe version conflicts are still easier to deal with (if conflicting versions are saved alongside each other) than the current situation, where person A opens a file, person B opens the same file, A saves, then B saves, but only B's version remains. All of A's work is lost, and neither A nor B get notified of this problem. (I hope I got this right?!) |
|
If using sync, and person A opens a file, person B opens the same file, A saves, then B saves, B gets a warning and A's version doesn't get overwritten. If using web UI, it does get overwritten, but A's version would be in the version history; if using webdav access I think that would still be true. If you want to sync lock files, then (depending on the variety) you'll need to do one or more of the following: |
|
@idmacdonald If you can implement it, then I think the best way to go forward is to do it by yourself. You could either make a PR to this repository or create an app for that. An app is more flexible because you can publish them rather freely on your own schedule whereas in core you would be bound to the release schedule of Nextcloud (and the uncertainty whether your PR is accepted). |
|
Look, guys, if you have customers who want this - why not make it happen? Contact our sales team. Become a reseller. Sell the customer a support contract with consulting for this feature and it is done... Or built it yourself. @putt1ck made this work for his customer, just like we make things work for our customers. Why not do the same? |
|
Yeah, file locking is something that is needed for some things I have in the pipe too. What's going on here? Are we going to let this issue rot like it has the last year+, close it, or actually talk about what we can do about this? Because really, no response since...mid last year? really isn't cool. Really need input as to what the NC devs think on this one! |
|
Considering this very github issue was opened in 2016, and has been revisited repeatedly since then, I'm not sure how it's concluded that the feature is not a desired feature (by free/paid client base). Plenty of other features get baked into NC all the time that don't require "strong customer demand" (which actually is what people are trying to convey in this, and other github issues). To say it succinctly, there is strong customer demand. Many people have asked for it, and even stated they went with SeaFile (or others) instead because of a lack of file locking. How is that not sufficient visibility of demand? |
|
The issue I opened (nextcloud/desktop#83) is very similar, even if it's a slighlty different need: locking is not what I need in priority, I would already be happy if I "know" that somebody is editing a file. And I could imagine these steps: (Client = Desktop Mirall Client):
Would it be a good solution for you also? Without locking feature, would it need 1 year working time to develop this? |
|
@putt1ck the chicken-egg you describe exists, of course, and picking a feature you think the market needs is always a little bit of a gamble. We do that, for sure, as I mentioned in another place where we discussed this, we make strategic decisions based on needs from customers we are told about or needs we see coming in the future. And I personally think this is a thing we should look into more, even though I must admit I never met a single (potential) customer at any event who ever asked about it or brought it up - and they bring up lots of stuff. Sales never told me about it either, so (almost?) nobody has shown interest to them. People show interest in other things, so that isn't because they don't see Nc as a viable solution just because it doesn't have this feature described somewhere... So I have nothing to argue for this feature when we meet in a week or two to discuss Nextcloud 14 priorities: I can say I have a hunch and 5 people on the forum who want a feature but that means it falls of the white board compared to every other priority we have. Wrt plugins, if people would be developing patches or separate versions of the client for specific purposes, we could take that as evidence for a need for a plugin structure. I haven't seen that and a plugin structure doesn't take away the need to write code. We barely get any contributions to the client from outside so there doesn't seem to be anyone who wants to write C++ client code - plugin or not. Again, putting in a lot of work (depending on what the plugin should be able to do this could mean rewriting half the client, a multi-year effort) so maybe maybe one person writes a plugin seems not a great idea. @biva in theory, that could be developed, and it would not take that long, because it is only useful in one very limited case: windows+Microsoft Office users. You might say "but that solves our use case" and you're not wrong. However, the problem is: if we do this, people will expect it to always work. Also if they open an image in Gimp on Linux. Unless we develop a solution that works for every situation we are unlikely to implement this in our mainstream product and advertise it as a feature: it creates confusion. People will expect more and be disappointed when it does less. You and I and the techies here probably understand that it was only implemented for MS Office because that was doable - but a average user won't understand why his Photoshop file now has a conflict and he/she didn't get warned. It IS possible, on every platform for every app there are ways to track if a file is opened. But then you're back to the "1 year working on this"... If a customer comes and pays us to develop the scenario you describe, we'd do it, of course - and it wouldn't take too much time. But we would probably NOT integrate it in the public version of Nextcloud, unless it works very well somehow or, of course, we see demand and decide to make a 'full' implementation. |
|
@jospoortvliet thank you sincerly for your clear and educational information: we, users, also need to understand your priorities and your way of taking decisions. I also understand your fear about the confusion it could create. However, I think it's overestimated. First, everybody (almost) understands that you can edit a document within Nextcloud web interface (with Collabora), and not a picture. No confusion. But most importantly, I think that a very large majority of usecase do affect MS Office or Libreoffice documents. Don't you think? I do agree that it should be available on all platforms, and on other softwares. I think MS Office and LibreOffice are a very good start, covering the main usecases. Both create a file which is easily recognizable ( Regarding other platforms, I don't have any Linux nor MacOS available, but I imagine that it works in a similar way: are there Linux and Mac users around to confirm this? |
|
@jospoortvliet I literally have a client that is going with SeaFile instead of NC because of the file locking. It would be very much appreciated if you could bring it up at the NC event, as I myself don't have the means to attend such events at this time. |
|
New insight from a friend of mine in Paris, system admin for several companies: they don't go Nextcloud only because of the lack of file locking (or similar feature). |
|
@biva There is a file locking app. Just not one like local shared drives (because you can't sustain it in a shared collaborative work environment). |
|
@putt1ck Do you speak about https://github.com/newroco/W2G2 ? As far as I understand, it locks file in the Web UI, not on the desktop. That's not what I'm looking for. |
|
Yes, I mean w2G2. Describe to me how locking on the desktop works in a system designed to support "off LAN" users and we'll add it to our list of "apps we want to build". If someone is considering NextCloud as an essentially LAN-focused setup, there's an easy workaround vis a vis file locking for the LAN users. |
|
Thank you for your interest @putt1ck |
|
I'm not a dev either... The idea of locking feature that only works with one product doesn't fly as something NC core (or our team) would work on. As described and implemented by Dropbox it has potential to cause user confusion in any org that doesn't only use that desktop software (for example graphics, CAD, GIS, audio/video). The feature as described by DropBox (pay for version) also seems no more user-friendly that pressing a button to say you're editing (and then it encompasses people opening just to view). What happens if someone is editing off-line? Or start editing when they are on line and then go offline before they close the document? Or with the MS Office feature, what happens if someone collaborating on the doc isn't using MS Office? What if it was just a button you had to press, like on W2G2 in the web UI, but also available on the sync client? That I could see working. |
|
|
@putt1ck there are technical nuances to figure out for sure, but there are more and more clients that are passing up NC while we sit here and just say it won't be done. When is enough... enough? Not only that, how about we flip this on it's head. Don't we want NC to be the BEST file sharing tool we can make it? It's clear people want this feature, and not having it prevents it from being the best. |
|
For the record, here is the Seafile feature: "File locking: Seafile supports file locking to prevent concurrent editing of files and generating of conflicts files. Users can lock files in web UI or desktop clients. Office files are automatically locked when they’re opened." We're not that far away from having this in Nextcloud:
|
|
@putt1ck you mentioned a workaround, can you please elaborate on that or share a link about it? btw, I've been struggling with this a lot, this is what I've tried so far:
edit: I also acceded NC via webDAV using other sync clients such as Goodsync and Cyberduck (and many others), but couldn't find any that supports locks. |
|
@jocarren afaik, the workaround is this one: nextcloud/desktop#83 (comment) |
|
@jocarren my vote is that we get file locking through the desktop sync client (nextCloud preferably, not the ownCloud one). I don't use WebDAV myself, but since it seems you do, I can understand why you care for file locking for that. I think we should get file locking regardless of the protocol used, but perhaps to start, have it enforced through the desktop sync client. |
Look, it isn't so complicated:
@putt1ck I appreciate the work you do to keep W2G2 working! And all of you are, of course, welcome to contribute these features. If any of these companies who is interested is a serious enterprise (eg 1K users or more), tell them to ask us, or, heck, become a partner, resell them a support contract. If we get a few asking for this, we can develop it. I'll close this now for discussion, we're not adding much new info. |
|
@jocarren the workaround in question assumes that the use case for Nextcloud is just an alternative to Dropbox or WeTransfer etc. i.e. a way for people to access files from home etc.. |
|
See also discussion in #9969 |
|
Hey, I think an important first step would be to inform the user, that another user is editing the same file at the moment. |
|
Well there is the locking app. So that covers the basics yes |
|
There's been a locking app for a while e.g. W2G2. Not sure that nor the new one covers the request to have webdav locks. |
|
@putt1ck the new lock file app include proper webdav locking properties. |
and others
It would be really nice to have true file locking in NC, such that opening a file prevents editing/opening by a second user until closed. I'm aware this has been discussed pretty heavily in the OC github, but I was hoping the opinion may be different in NC.
Our main use would be through webdav; however, it would probably be necessary to honor the lock in the web interface and possibly also the sync client.
This issue has been brought up (independently) time and time again by our customers, so it's a much sought after feature from our client base.
Steps to reproduce
Expected behaviour
User2 shouldn't be able to open and/or save their changes because User1 already had FileA open
Actual behaviour
The changes that User2 made overwrites the changes that User1 made. This is done without any notice/message/warning to User2 or User1. Neither are even aware that changes were overwritten.
The text was updated successfully, but these errors were encountered: