[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
AW: [geclipse-dev] AW: [Bug 228185] BufferOverflowException duringopening output file for files from gLite sandbox
|
> > Well, this is a problem of the EFS definition and our implementations.
> > fetchInfo() actually should always contact the underlying filesystem and
> > should not cache things. Nevertheless, since the EFS resource
> > integration is so bad and therefore fetchInfo is called all the time
> > (e.g. from within context menu activations or decorators or whatever)
> > for remote filesystems we have no other chance than to cache things.
>
> well, cache things yes, but not "inconditionally and forever"
> If there is a way to pass a flag as Mariusz mentioned already, that should
> be a reasonable possibility, telling it: ok, now fetch the fileInfo for
> real.
The problem here is that EFS does not specify such a flag for fetchInfo.
<cite>
options - bit-wise or of option flag constants (currently only EFS.NONE is applicable).
</cite>
Therefore I was asking Mariusz which FORCE he meant. There is no FORCE specified for EFS. But there is one for IResource! But we should definitely not make use of this since this is coming from another namespace and therefore collisions may occur with real EFS attributes!
> i cannot believe that you Mathias are saying that ;-)
Well, still able to learn :-P
> But i hope we will be able to prevent BufferOverflowException's in our
> tool!! ;-)
I mean it is always a question of performance. We could also make use of a dynamic buffer that grows with the bytes read from the file. Nevertheless this would of course mean a continuous memory allocation. This is not the worst idea but may - as I just said - be not that performant. Nevertheless I will have some tests with a dynamic buffer ... after M5 ;-)
> Can't we just retrograde the situation to the last-changes - 1 ?
As we Germans say: HÄ?
Nevertheless, do not talk about additional choices. The choice is either 1) (old opening strategy, untouched EFS, safe but lost feature) or 2) (new opening strategy, fixed EFS, risky but cool new feature).
Mathias
