Community
Participate
Working Groups
When I double click or right click Open on a file inside a tar file on Local Windows nothing happens. We should be able to open files inside tar files. Rename/Delete/Copy to a tar archive work. -----------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 ------------------------------------------------
This only happens when open files inside local connection tar archive file. It works fine for virtual files inside DStore Windows and DStore Linux tar archive file. The reason is the following: For DStore server, UniversalDownloadHandler#handleDownload() calls VirtualChild#getExtactedFile(), which in turn calls VirtualChild#getExtactedFile(String sourceEncoding, boolean isText). In VirtualChild#getExtactedFile(String sourceEncoding, boolean isText), it will create a tmp file as the destination of the content of the virtual file first before it calls the ISystemArchiveHanlder#extractVirtualFile(). So the destination file always exists. For LocalFileService, its copyFromVirtualFile() method calls VirtualChild#getExtactedFile(File destination, String sourceEncoding, boolean isText). And the destination File object it passes to VirtualChild#getExtactedFile(File destination, String sourceEncoding, boolean isText) is constructed by the following code: new File(targetFolder, child.name) So the destination file may not exist (which is true in the scenario described here). It also calls to ISystemArchiveHanlder#extractVirtualFile(). And for SystemTarHandler#extractVirtualFile(), unlike SystemZipHandler#extractVirtualFile(), it did not check if the destination file exists or not. It just calls: outStream = new FileOutputStream(destination); to get the outStream of the destination file, which will throw an exception. To fix, change SystemTarHandler#extractVirtualFile() to behave like SystemZipHandler#extractVirtualFile(). That is, check if the destination file exist or not. and create a new file if the file does not exist yet.
While writing a JUnit testcase for the fix, I found that we could not copy a folder into a tar file in Windows Local. I think the assumption before was that tar file was for Unix/Linux Dstore only, and we did not expect it to work in Windows. That is why not much testing had been done on Tar on Windows Local. The reason that we could not copy a folder to a tar archive file is the following: In LocalFileService#copyToArchive(), if the target is a Virtual folder, it will call ISystemArchiveHandler#add(File file, String virtualPath, String name, String sourceEncoding, String targetEncoding, ISystemFileTypes typeRegistery). But the implemenation of this method in SystemTarHandler is the following: public boolean add(File file, String virtualPath, String name, String sourceEncoding, String targetEncoding, ISystemFileTypes typeRegistery) { // TODO Auto-generated method stub return false; } So it basicially doing nothing. And also found out that all the add() methods implemented by SystemTarFileHandler just ignor those parameters: sourceEncoding, targetEncoding, typeRegistery isText So to workaround the copy folder problem for tar file, we will change the implementation of ISystemArchiveHandler#add(File file, String virtualPath, String name, String sourceEncoding, String targetEncoding, ISystemFileTypes typeRegistery) in SystemTarHanlder to the same as its implementation of ISystemArchiveHandler#add(File file, String virtualPath, String name, String sourceEncoding, ISystemFileTypes typeRegistery). I will open an enhancement bug for us to include handling those parameters in tar file processing.
Created attachment 76018 [details] Fix for the bug 199132 Fixes added: . Change SystemTarHandler#extractVirtualFile() to behave like SystemZipHandler#extractVirtualFile(). That is, check if the destination file exist or not. and create a new file if the file does not exist yet. . change the implementation of ISystemArchiveHandler#add(File file, String virtualPath, String name, String sourceEncoding, String targetEncoding, ISystemFileTypes typeRegistery) in SystemTarHanlder from empty to calling add(File, String, String). A JUnit testcase has been added to test downloading files from a Tar file. I've also moved all the Tar file related testcases to FileServiceArchiveTest (so that they could be run in Local connection), and also ran them in Local connection. I will check in the JUnit testcases separately.
I've committed the patch. And checkin the JUnit changes.
What about the other methods in SystemTarHandler which are marked as //TODO Auto-generated method stub ?
The other empty methods are: public boolean replace(String fullVirtualName, InputStream stream, String name, String sourceEncoding, String targetEncoding, boolean isText) { // TODO Auto-generated method stub return false; } public boolean add(InputStream stream, String virtualPath, String name, String sourceEncoding, String targetEncoding, boolean isText) { // TODO Auto-generated method stub return false; } Those method never got implemented before, and there is no quick workaround fix for them as well. I will also open an enhancement bug for providing the implementation of those two methods. Currently, those two methods are not used. Even LocalFileServer#upload(InputStream stream, String remoteParent, String remoteFile, boolean isBinary, String hostEncoding, IProgressMonitor monitor) calls add(InputStream stream, String virtualPath, String name, String sourceEncoding, String targetEncoding, boolean isText), no method calls the upload() method.
Verified fixed with 2.0.1RC1.
