Community
Participate
Working Groups
- open a read only file (ftp/ssh/rse-server) - edit the file - save it - you get an error message (as expected) BUT: the editor shows the new content and the remote file has the old content! To get the real content, you have to delete the cache file. Expected: - don't allow the file to be edited - or keep the buffer modified
I tried it with: 1.0 and N20061124-0100
That sounds severe! Dave can you look at it?
I've changed things so that the IFile has it's read only attribute set appropriately. When a readonly file is opened in an editor the buffer can't be modified without being prompted to change it to writable. If the user choses to make it writeable, however, we can't prevent the edits from happening. This at least makes the user aware. Do you think that's enough?
Well' that's better than now. But if the user modifies the file a synchronize (or the failed save) should get back the original unmodified version. I think it is really bad if the files are out of sync and there no way to get the target version (except doing low level thing like deleting the cache file)....
Only concern I have with that is that local user changes would be lost. At least with the current approach, the user (who changed the local copy to writable) could later modify the host permissions and then attempt the save again.
The change which makes the user aware of the read-only file looks good. I think that in the future, we'll want the "change to writable" operation to actually change the remote file to writable. We'll need new API to cover this. This is covered in bug 165171 for now, but we might want to make a new bug entry for explicitly covering the r/w API. The issue of potentially overriding local changes when the user re-synchronizes with the remote side is covered by bug 143462 -- when the local file cache is "dirty" and about to get updated by something new from the remote side, the user should be notified and prompted to either keep or revert the editor buffer, just as Eclipse does it when changing a file on the disk outside Eclipse. What I don't like with the current solution is that the local file cache is deliberately out-of-sync with the remote side: it has different contents, and different file permissions than the remote side. Perhaps a better solution would involve using the File Conflict dialog: * When the user tries to save the editor, RSE tries to upload * Upload fails because the remote file is read-only * RSE should display a conflict dialog, and allow the user to save with a different name [or change remote file permissions outside RSE and retry] What do you think about this?
I like the idea of allowing the user to save as a different file name. I don't know if the conflict dialog is the right thing to use because the option of overwriting the remote file is not really available - perhaps we need an additional save-as dialog. However, I wonder if we can defer that until 2.0 - maybe with a separate defect.
I'm dropping the severity of this since the read only attribute is now set properly. I'll leave it open (but targetted for 2.0 to deal with the proposed save-as dialog.
I'm marking this future since the save-as portion is really a feature.
Reassigning all API related to 3.3
Moving deferred 3.3 api items to 3.4
We are post API freeze.
