Community
Participate
Working Groups
If I make a file/folder read only the output from the list command shows that it has changed, but sometimes the file in the properties view/dialog doesn't show the file as read-only. Refresh Listing output shows: -rw-r--r-- 1 tester users 0 Aug 10 16:09 efs_read_only.php -r--r--r-- 1 tester users 0 Aug 10 16:12 read_only.php Both files in the properties view display as read-only, but only read_only.php should be read-only. If I refresh the grandparent of the file then it will display the proper read-only attribute. Refreshing the parent doesn't help. I see this issue more often when making a file not read-only. Generally making a file read-only doesn't have any problems. -----------Enter bugs above this line----------- TM 2.0.1 Testing installation : eclipse-SDK-3.3 RSE install : Dev Driver - java.runtime : Sun 1.5.0_11-b03 os.name: : Windows XP, Service Pack 2 ------------------------------------------------
Bulk update target milestone 2.0.1 -> 3.0
It looks like multiple missing refresh operations play together here. With SSH, I can properly change the attributes of files; but when setting a file "not-executable" the Properties view doesn't update. Also, RSE-Properties are NEVER refreshed when I change permission bits of a folder. On Local and DStore, this might work since they always re-use the same IHostFile so they immediately know about updated file status. On FTP and SSH, Refresh of the IRemoteFile must be forced. I consider this a high-priority fix since it blocks bug 220302. Please investigate as soon as possible. Bug 234038 also seems related and should perhaps be addressed first, because that one fails on dstore as well.
Created attachment 102188 [details] patch for refreshing file on change of read-only bit Martin, does this patch help?
Patch helps for the default Property Page, on which I can set/reset the "Read-only" flag. Now, when I press Apply, properties of the specified file are immediately updated. BUT (1) Trying to set a folder read-only doesn't refresh properly. FTP Console Log shows that the folder is set read-only, but in the SystemView the current selection changes to the root filter (should remain on my Home/aaefs). And, when selecting the folder in question again afterwards, the Properties View does not show the folder read-only (although it is physically). (2) Changing Permissions on the "Permissions" property page e.g. setting a file group-writable shows that the command is executed on the Server, but the Properties View / RSE SystemView are not refreshed. In other words, patch is a first step but not yet the full story. Feel free though to add a Copyright Header to the patch and commit it since it also doesn't break anything.
It looks like (2) is addressed by bug 234038 already, and (1) is actually the same issue here and in bug 234038. The problem (1) only occurs when the currently selected folder in question is expanded; it works correctly when the folder is collapsed.
(In reply to comment #5) > It looks like (2) is addressed by bug 234038 already, and (1) is actually the > same issue here and in bug 234038. The problem (1) only occurs when the > currently selected folder in question is expanded; it works correctly when the > folder is collapsed. So since these other problems are in different bugs, shall I commit the patch for this and close it?
The problem described here is not yet fixed for expanded folders, and while that issue is duplicated by bug 234038 I'm not aware of any bug that specifically deals with that issue... So, I'd suggest committing the patch but keeping the bug open until what's described in the Summary is actually resolved.
Created attachment 104354 [details] patch to refreshing file on change of read-only bit This patch seems to resolve the refresh issues for ftp files and folders after changing the read-only bit.
Dave -- What does this patch do? It looks like it requests a parent folder refresh on a permissions change. Are there potential performance problems with this? After applying the patch I attempted various permissions changes on a *file* using the permissions property page and sometimes saw no change in the properties view and sometimes did. Sometimes just bringing up the properties dialog had the effect seeming to alter the permissions. This happened for dstore, ssh, and ftp and when either OK'ing the change or Applying the change. I ran the same tests with the "Info" page and read-only property with similar results. Under FTP If the selected resource was a *folder* then OK'ing a change from the Info page refreshes, but Applying the change does not refresh the Property Sheet even though the permission is actually changed on Apply. Under SSH I see the same behavior. So I'm not sure this last patch actually fixes the problem.
(In reply to comment #9) > Dave -- > What does this patch do? It looks like it requests a parent folder refresh on a > permissions change. Are there potential performance problems with this? > After applying the patch I attempted various permissions changes on a *file* > using the permissions property page and sometimes saw no change in the > properties view and sometimes did. Sometimes just bringing up the properties > dialog had the effect seeming to alter the permissions. This happened for > dstore, ssh, and ftp and when either OK'ing the change or Applying the change. > I ran the same tests with the "Info" page and read-only property with similar > results. > Under FTP If the selected resource was a *folder* then OK'ing a change from the > Info page refreshes, but Applying the change does not refresh the Property > Sheet even though the permission is actually changed on Apply. > Under SSH I see the same behavior. > So I'm not sure this last patch actually fixes the problem. Please note that this patch is NOT for the permissions page - it's only for the read-only property on the Info page. This patch just updates the remote file that changed via the refresh remote event. With recent changes to refresh remote handling in the system view, we now update the object to refresh as a result of a query on a container (like a folder). Previously we had to refresh it's parent in order to update the properties of a folder (now we just do that for files). Could you describe which systems you did this on? On dmcknigh3 Kevin and I have had no problems with the patch.
Does it fix the Apply button as well as the OK button? Is there a bug for the permissions page as well then?
(In reply to comment #11) > Does it fix the Apply button as well as the OK button? > Is there a bug for the permissions page as well then? Oh, that is an issue. In my tests I was using OK, not Apply. For Apply, we'll need to update the underlying element for the dialog.
Created attachment 104498 [details] updated patch Investigating this further I noticed the following: 1) that a property sheet event won't update the property sheet via Apply, because we've got code that prevents this update if the view with item to update is not in focus (and when the dialog is up, the system view is not in focus). 2) We should no longer need to do a refresh after a setReadonly() when using the FileServiceSubSystem. The FileServiceSubSystem ought to call the new updateRemoteFile() call after any set operation. By doing that, we can continue to use the original IRemoteFile. I've made changes to the patch for these cases. I'm still a little worried about addressing (1) because we put that code in there as a big performance improvement.
I guess this will have to wait to go into 3.0.1.
(In reply to comment #13) > I'm still a little worried about addressing (1) because we put that code in > there as a big performance improvement. Could we argue like this: If the "REFRESH_REMOTE" event comes from a source other than the SystemView, there is no reason for the SystemView to also care for Propertysheet. The PropertySheet either needs to listen to EVENT_REFRESH_REMOTE itself and refresh itself when its currently displayed item matches the item in the event (preferrable solution!), or the event sender needs to care for refreshing the Propertysheet because it is responsible for making the change. I think that the correct solution should be that each view is responsible for refreshing its contents when receiving a REFRESH event. One problem with RSE is that the meaning of REFRESH event is that receivers need to get fresh contents from the remote. So, if the IRemoteFile in question is not yet stale, many views could want to start retrieving the file. As I have said several times before, I think what we need is an event that tells views to refresh themselves based on the current model, without retrieving new data from the remote.
Moving some bug milestones from 3.2.1 to 3.2.2.
Bulk moving 3.2.x bugs to 3.3
Bulk moving 3.3 deferred items to 3.3.1
Not updating the remote seems severe to me - could this be addressed ?
