Re: [geclipse-dev] AW: [Bug 228185] BufferOverflowException during openi

[Ariel Garcia <garcia@xxxxxxxxxx>]

Hi all,

> 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.

> > 1. User A modifies file F. Saves the changes, correct file size is
> fetched.
> > 2. User B modifies file F.
> > 3. User A opens file F. He will get BufferOverflowException.
>
> What you describe here is a synchronization problem that you will ALWAYS
> have when dealing with remote file systems. You cannot prevent this. So
> we will make no attempts to solve this case.

i cannot believe that you Mathias are saying that ;-)
Of course file operations on gridftp etc are not atomic and you cannot 
prevent interleaving operations on the same file. 
But i hope we will be able to prevent BufferOverflowException's in our 
tool!! ;-)

<neverLookedDeeplyAtThatCodeMode>
We shouldn't allocate a buffer with the size reported by some (cached or 
not) file size query (fileInfo), but be more flexible and allocate space 
as necessary when data is coming in from gridftp, or using such a 
predefined buffer is required by EFS?

Can't we just retrograde the situation to the last-changes - 1 ?

</neverLookedDeeplyAtThatCodeMode>

> Allocating a bigger buffer is nonsense as I think. How big should the
> buffer be? Twice as big as needed? Forget about it, no way.

yes, that would only the problem appear for less cases but never go away. 
Forget it.

Cheers, Ariel