Bug 246972 - g-Eclipse with Ganymene download EFS file content after listing folder
Summary: g-Eclipse with Ganymene download EFS file content after listing folder
Status: NEW
Alias: None
Product: z_Archived
Classification: Eclipse Foundation
Component: Geclipse (show other bugs)
Version: unspecified   Edit
Hardware: All All
: P3 critical (vote)
Target Milestone: ---   Edit
Assignee: Mathias Stümpert CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-09-11 05:15 EDT by Mariusz Wojtysiak CLA
Modified: 2014-01-09 16:00 EST (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mariusz Wojtysiak CLA 2008-09-11 05:15:04 EDT
1. Start g-eclipse with Ganymede release.
2. Mount new connection (gsiftp/srm/gria - it doesn't matter) where you have text or xml files
3. List folder with txt files

Result:
In the background content of some listed files are downloaded.

In fact I didn't noticed that problem, because this background downloading doesn't disturb my work.

But Mathias complained about this, so I checked it under debugger.

Now I can confirm: content of some files are downloaded. I believe that users with slow connection may notice that unwanted transfer.
Comment 1 Mariusz Wojtysiak CLA 2008-09-11 05:24:11 EDT
I checked what initialises that background transfer: it's new Ganymede label decoration called "File Icons Based On Content Analysis"
This decoration is described in what's new section for Ganymede release.

It's possible to disable it in Preferences / General / Appearance / Label Decorations

From my observation I see that this decoration:
- read content of only some files: txt, c, xml, log (files recognized as text, based on file extension). So binary files are not read.
- read content of file only once. Then results are stored somewhere in the workspace and during next g-eclipse start content for previously read files aren't read
- read content of file after modifications like renaming

My proposition is to add this problem to user help in open issue section. There we can describe how to disable that label decorator.
Comment 2 Ariel Garcia CLA 2008-09-11 05:26:49 EDT
Yes, it also downloads the content (again) when deleting a file...
Comment 3 Ariel Garcia CLA 2008-09-11 05:34:51 EDT
You were too fast Mariusz ;-)
I posted my changes before reading yours.

Anyways... i'd rather try to disable that programatically by default from inside gEclipse for all our remote connections, and let the users reenable that from a preference page.
Remember that reading the "known issues" or the documentation or ... is not done so often!... or at least after people encounter the issues ;-)
Comment 4 Mariusz Wojtysiak CLA 2008-09-11 05:41:10 EDT
I doubt if there is a possibility to disable that decorator only for remote files.

I think we can disable this decorator at all (for all files, also local).

But maybe we can disable it only in our GridProject and Connection view? It's something to check.
Comment 5 Markus Knauer CLA 2008-09-11 05:43:33 EDT
A few days ago I checked the N&N docs again and found the entry about the new label decoration feature. I found it suspicious and as it turns out now, this seems to be the reason for this misbehavior in g-Eclipse.

I think we should open a bug against platform that this causes a regression in the EFS implementation.
Comment 6 Mathias Stümpert CLA 2008-09-12 04:04:44 EDT
The download of remote files does also happen in other places with Ganymede. Here are those I am already aware of:

1) When deleting a file. The reason here is that the resource management downloads the file content for use in the history. So in principle it is possible with that to undo the delete. But I doubt that we need this "feature" for remote files and I did not yet check if an undo is even working for EFS links. Nevertheless I do not yet have an idea how to disable this feature for remote files.

2) When closing g-Eclipse with a remote file opened in an editor. The behaviour here is veeery strange. The file content is downloaded into a remporary file which is created with deleteOnExit(), so this file will in any case be deleted after g-Eclipse shutdown. The purpose of this file is to get a local path to be stored in the editor's memento to be able to re-load the file when Eclipse is started again. But since this local copy was already deleted ... So really nonsense here. A possible solution here would be to open the remote file (we already have an own open action for those remote files) with an own IEditorInput implementation. Currently it is opened with the standard FileEditorInput which causes these problems.

These were my investigations up to now. But I would not rely on this list. After these investigations I would rather assume that there are even more pitfalls with remote files now and therefore we should really carefully investigate EFS behaviour with Ganymede.
Comment 7 Mathias Stümpert CLA 2008-11-27 08:02:31 EST
Ok, the issue with downloading file content when deleting a file is solved (see also #242503).