Community
Participate
Working Groups
After doing a copy from Local to dstore to a folder that has subfolders, some of the subfolders show the name "deleted" and can't be expanded. Refreshing the parent doesn't fix it. Need to refresh the grandparent. This happens for me when doing a copy from Local to Dstore, but not Dstore to Local. Steps to Reproduce: 0. Start with a clean workspace. 1. Copy a folder from Local. 2. Create a dstore connection. 3. Paste the folder copied to a folder that has subfolders on the dstore connection. --> Some of the folders names are now "deleted". -----------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 ------------------------------------------------
I did not see this problem when I first enabled the supertranfer when fixing bug 191367. But I could reproduce it now. If I set a breakpoint at UniversalFileSystemMiner#handleQueryAll() method in my remote Java Debug session right before the "argetFS.delete(remoteArchive, monitor);" call in UniversalFileTransferUtility#compressedCopyWorkspaceResourceToRemote() (this call is used to remove the intermedia zip file in the target file system), and this breakpoint is hit, and the folders inside the target directory are displayed correctly (always). But without hitting the breakpoint, I always hit this problem. It seems to me a timing problem. Need more investigation.
In supertransfer support, we need to remove the intermedia archive file from the source and target file subsystem. Since the intermedia archive file has never been cached before, a default Filter Object DataElement will be created before we send down "DELETE" command to dstore server. This is not correct, since delete command could not handler an filter object. To workaround this limitation, I call resolveFilterString of the file subsystem to generate the cache information for this archive file. I used this version of resolveFilterString() method before: targetFS.resolveFilterString(newPath + RemoteFileFilterString.SWITCH_NOSUBDIRS, monitor); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ where newPath is the absolutePath of the intermedia archive file. I thought it would reduced the # of DataElements sent back to the client (only the information of the archive file, instead of all the file/folder inside the target folder). But it turned out this call also send back the DataElements of the other file/folder inside the target folder, and marking all the folders existed there as deleted. So we need to change this resolveFilterString() call to: targetFS.resolveFilterString(newTargetParent, null, monitor); I also added the similar resolveFilterString() call before deleting of the intermedia archive file from source file subsystem.
Since the fix for bug #202268 is also in file UniversalFileTransferUtility.java, and it is only one line fix, I will include it in the same patch here.
This regarding to comment #3. Got the bug number wrong. The text should be: Since the fix for bug #202668 is also in file UniversalFileTransferUtility.java, and it is only one line fix, I will include it in the same patch here.
Created attachment 78133 [details] fixes for both bug 206670 and bug 202668
Dave, Could you please review the fix? The reason I put: cpdest.getParentRemoteFileSubSystem().resolveFilterString(cpdest.getParentRemoteFile(), null, monitor); outside the cleanup() method is because I could pass "monitor" into resolveFilterString.
It seems odd that we have to cache the file just in order to delete it, but it sounds like you know what you're doing.
Originally, I was thinking of modifying the DELETE command in dstore server to handle the case where the object to delete was a FilterObject. But from the design of the DStore UniversalFileSystemMiner, DELETE command is not supposed to be supported for a FilterObject (which makes sense to me). This is the fragment of UniversalFileSystemMiner#extendSchem(): // Define command descriptors DataElement queryAllFilterDescriptor = createCommandDescriptor(UniversalFilter, "Filter", IUniversalDataStoreConstants.C_QUERY_VIEW_ALL); //$NON-NLS-1$ _dataStore.createReference(cancellable, queryAllFilterDescriptor, DataStoreResources.model_abstracts, DataStoreResources.model_abstracted_by); DataElement queryFilesFilterDescriptor = createCommandDescriptor(UniversalFilter, "Filter", IUniversalDataStoreConstants.C_QUERY_VIEW_FILES); //$NON-NLS-1$ _dataStore.createReference(cancellable, queryFilesFilterDescriptor, DataStoreResources.model_abstracts, DataStoreResources.model_abstracted_by); DataElement queryFolderFilterDescriptor = createCommandDescriptor(UniversalFilter, "Filter", IUniversalDataStoreConstants.C_QUERY_VIEW_FOLDERS); //$NON-NLS-1$ _dataStore.createReference(cancellable, queryFolderFilterDescriptor, DataStoreResources.model_abstracts, DataStoreResources.model_abstracted_by); createCommandDescriptor(UniversalFilter, "Filter", IUniversalDataStoreConstants.C_QUERY_ROOTS); //$NON-NLS-1$ . . . createCommandDescriptor(UniversalFilter, "GetOSType", IUniversalDataStoreConstants.C_GET_OSTYPE); //$NON-NLS-1$ createCommandDescriptor(UniversalFilter, "Exists", IUniversalDataStoreConstants.C_QUERY_EXISTS); //$NON-NLS-1$ createCommandDescriptor(UniversalFilter, "GetRemoteObject", IUniversalDataStoreConstants.C_QUERY_GET_REMOTE_OBJECT); //$NON-NLS-1$ createCommandDescriptor(UniversalFilter, "CreateNewFile", IUniversalDataStoreConstants.C_CREATE_FILE); //$NON-NLS-1$ createCommandDescriptor(UniversalFilter, "CreateNewFolder", IUniversalDataStoreConstants.C_CREATE_FOLDER); //$NON-NLS-1$ createCommandDescriptor(UniversalFilter, "SetLastModified", IUniversalDataStoreConstants.C_SET_LASTMODIFIED); //$NON-NLS-1$ . . . So with a blank new workspace, and I did supertransfer the first thing, the DELETE command was not sent to the server. That is why I need to cache the object information for the object first. But I did find out (without my fix) if I had issue a "DELETE" command before (for a file/folder in the SystemView), the "DELETE" request for deleting the intermedia zip file will be sent to the server. Since server did not know how to handle it, a message was issued, and this intermedia file was not deleted. The reason this DELETE command was sent to server even "DELETE" command is not supported for an FilterObject is the following: In AbstractDStoreService#dsStatusCommand(), we called: DataElement queryCmd = getCommandDescriptor(subject, command); where subject is a DataElement of type FilterObject, and command is "DELETE" And this is the AbstractDStoreService#getCommandDescriptor() method: protected DataElement getCommandDescriptor(DataElement subject, String command) { DataStore ds = getDataStore(); DataElement cmd = (DataElement)_cmdDescriptorMap.get(command); if (cmd == null || ds != cmd.getDataStore()) { cmd = getDataStore().localDescriptorQuery(subject.getDescriptor(), command); _cmdDescriptorMap.put(command, cmd); } return cmd; } In this case, since "DELETE" command had already been issued before (on a FileObject/FolderObject), it is already in the _cmdDescriptorMap. So the call cmd = getDataStore().localDescriptorQuery(subject.getDescriptor(), command); was not needed. But the method localDescriptorQuery() is the one which checked if a command is supported for a particular type. I am not sure if this behaviour is working as design? From my option, it is not. In the scenario I described here, we should not even send the "DELETE" request to the server.
Went through the code with DaveM, and he mentioned that DStoreFileService#getFile() method (which is invoked by IRemoteFileSubSystem#getRemoteFileObject() should also need to put the DataElement of the query object into DStore filemap. So, change DStoreFileService#getFile() to the following: public IHostFile getFile(String remoteParent, String name, IProgressMonitor monitor) { . . . dsQueryCommand(de, IUniversalDataStoreConstants.C_QUERY_GET_REMOTE_OBJECT, monitor); //getFile call should also need to convert this DataElement into a HostFile using //convertToHostFile() call. This way, this DataElement will be put into _fileMap. return convertToHostFile(de); ^^^^^^^^^^^^^^^^^^^^ } convertToHostFile() will take care of putting the DataElement into the file map.
Created attachment 78231 [details] updated fix according to DaveM's comment.
I verified the scenarios in 2.0.1 RC1 driver, and it worked fine. Kevin, could you please also verify it? Thanks.
Verified fixed with 2.0.1RC1.
