Version: 1.3 (using KDE KDE 3.2.0) Installed from: SuSE RPMs OS: Linux In order to avoid that a file is opened more than once an is written to accidentally from each of the open windows, so that the work on another 'instance' is lost, the file should only be opened once in write mode. All the other instances should bee in read-only mode and show it, possibly by adding 'read-only' to the title bar. Notifying the user that he is in read only should also be done in a similar way (beforhand) when he has no write permissions on the file. See the discussion on the koffice-devel mailing list starting 10/04/2004. This behaviour is probably desirable for all KDE programs that edit files. It is not a wish for KWord or KOffice alone. Marc Heyvaert
The thread is in: http://lists.kde.org/?t=107891176200004&r=1&w=2
A related issue that is probably common in mixed environments: The company I work for uses MS Windows *and* Linux. Office documents reside on a SMB share. As long as only MS Office / Windows is used users are notified if they're trying to edit a document someone else has opened. But if I do it from my Linux machine this does not work: I browse the share using the smb:// protocol and click a document. The file is downloaded, OpenOffice comes up, I make my changes, save it and exit. Then KDE asks me if I want to upload my version. This overwrites any concurrent changes made by colleagues. From a user's point of view (and from the PHB's) this is critical because hours of work may be lost that way, without even noticing. At least at first :-). (Yes, this is not koffice-specific, but that's what the original wish states, too.)
Wow. Now please, if this ever gets implemented, remember us enriched souls taht hav nothing to do with windows at all, and who work in CVS in all it's glory... and put a switch to alternatively turn it off. A smarter approach tahn the proposed, and that could make everyone happy could be the one adopted by KATE - warn a user whenever a file has changed on disk - menaing that the other party using it had commited his changes - and offer to reload. Even smarter than Kate would be the ability to merge, like "patch" does, the copy being edited with the changes recorded in disk, in order to various people to be able to work on a file at the same time, with no one blocking nobody else. Regards, JS -><-
Yes, I can see that being able to work on the same document can have advantages, but I'm not sure it should be implemented like in CVS. It would be far better to be able to see all the proposed changes at once (using colors is a possibility) and to allow someone to do the final editing, accepting or rejecting the changes. As for the 'wish' itself. Consider the situation now : you get no warning and you can happily overwrite the work of a collegue. The 'Kate' solution. If I understand it correctly, you get no warning when you open a file but when you want to save you can still choose to overwrite, i.e. to throw away the changes made by someone else and all this without him knowing...Now, if you can only open in 'read-only' mode, at least you know that you will have to save under a different filename, or try to track down the guy that has the file open (having this info pop up could also be a feature of a possible solution). I can live with that.
I shouldn't have said that this problem is present in mixed Linux / Windows environments. Mentioning Windows always seems trigger a counter-reaction in some people ;-) It's also there if you have "only" several people with Linux machines working on documents on a Samba share. I don't know if the situation is any different if the share is properly mounted (instead of using an IO slave to access it), or if NFS is used instead. I'm not an expert on these matters, I just made some observations. > It would be far better to be able to see all > the proposed changes at once (using colors is a possibility) > and to allow someone to do the final editing, > accepting or rejecting the changes. That's a very nice idea of course, but this would mean implementing something like a content management system (and one with intimate knowledge about every file format that is involved at that). Using CVS as also mentioned above would only work properly for plain text files (so neither koffice, OO.o nor MS Office files). BTW: That's already available in quanta, AFAIK it uses a cervisia part as plugin. Dunno about other apps... > or try to track down the guy that has the file open Windows / SMB even manages to tell people who it is.
> A smarter approach tahn the proposed, and that > could make everyone happy could be the one adopted > by KATE - warn a user whenever a file has changed > on disk - menaing that the other party using > it had commited his changes - and offer to reload. Yes, that's a common approach, not only in KDE. Emacs does it this way, and Eclipse even warns you as soon as it detects a change, even before you try to save. But: - Does it work over IOSlaves? - Does it work with automatic down/uploading (for apps that don't support IOSlaves directly, like OO.o)? - What will you do if the app detects the file has changed (after you have spent an hour editing it)? How will you merge a koffice document? - It would be better than nothing, but being notified that you may have issues with concurrent changes *before* you make yours is a far superior solution, IMHO. So, no, this not an approach to make everyone happy.
Maybe for Samba just use "kernel oplocks" as described at http://www.oreilly.com/catalog/samba/chapter/book/ch05_05.html ?
Sharing files on a shared (network) drive is not a very good way to do collaboration. As you noted you need support from the application. But you also need support from the filesystem, the network layer and operating system. I'd like to suggest we focus our attention on alternative means of collaboration. See http://wiki.koffice.org/index.php?title=Collaboration for a couple of usecases of what kind of possibilities we could have based on that.
In reply to #6 - whenever authomatic detecting of a file change cannot be done at the time it happens, warning the user at save time should be enough (and not doing so, would be a bug in itself). I still say this Windows-like, lock users out approach, is simply broken. BTW, I think a "read only mode" is broken enough. I do not even know - is such a thing implemented in koffice? I know it is there in OO, and I dislike it a lot. >- It would be better than nothing, but being notified that > you may have issues with concurrent changes *before* you make > yours is a far superior solution, IMHO. I'd be allright with "being notified". Locking me out, is another issue.
Thank you for your bug report or feature suggestion. The "KOffice" application suite is no longer maintained, and all tickets are now closed. We recommend to switch to the "Calligra" application suite, which has replacements for all unmaintained KOffice applications: - KWord was replaced with Calligra Words - KPlato was replaced with Calligra Plan For more information, see http://en.wikipedia.org/wiki/Calligra_Suite (This is an automatic message from the KDE bug triaging team)