[Glass] Git based repositories (package-cache) problem when moving extent to another stone

Dale Henrichs via Glass glass at lists.gemtalksystems.com
Tue Oct 27 11:22:32 PDT 2015



On 10/27/2015 10:50 AM, Mariano Martinez Peck wrote:
> Dale,
>
> While that more robust #exists does help in the sense that the user 
> gets a much better error message, I think it's not enough.  So now I 
> get this message:
>
> ...RETRY->BaselineOfSeaside3
> ...RETRY->BaselineOfSeaside3
> gofer repository error: 'GoferRepositoryError: UserDefinedError: Disk 
> error:  for path: 
> /opt/gemstoneAdditions/GsDevKit_home/server/stones/gs_329/logs/github-cache/GsDevKit/Seaside31/v3.1.4.2-gs/GsDevKit-Seaside31-55f1bac/repository'...ignoring
> ...FAILED->BaselineOfSeaside3
Right, but aren't we trying to figure out why the load works when you 
remove the offending directory but does not work when you explicitly set 
the cache directory to nil:

   MCGitHubRepository cacheDirectory: nil

... when an extent is copied to a different stone directory there are 
potentially a number of places that need to be fixed ... basically 
anywhere that is going to look for things on disk ... the Smalltalk code 
that gets executed by $GS_HOME/bin/newExtent currently cleans up the 
tODE directory dependencies and it should also reset the github-cache 
directory (whether or not errors are going to be thrown because of 
permission errors)...

The $GS_HOME/sys/{default|local}/client/tode-scripts/rebuildSys script 
is intended to clean up these directory/stone dependencies for tODE and 
GLASS and you are expected to override with application-specific clean 
up code ....

Soooo is the above error happening before or after you have cleared 
MCGitHubRepository class>>cacheDirectory?

I am under the impression that:

   MCGitHubRepository cacheDirectory: nil

isn't working for you ... am I missing something?

> But my code still fail to load. There are a couple of places that 
> should be changed. Search for the string "*MCFileTreeFileUtils current 
> directoryExists:*"
> And you will find
>
> --------------------
>   MCGitHubRepository class>>resetCacheDirectoryIfInvalid
>  MCGitBasedNetworkRepository>>directory
>  MCGitBasedNetworkRepository class>>resetCacheDirectoryIfInvalid
> MCFileTreeRepository>>flushCache
>
> I think those guys should handle the error and on error, the flush or 
> reset anyway. To avoid this (adding error handling in all those 
> places), I suggested adding:
>
> MCFileTreeFileDirectoryUtils class >> directoryExistsAndValid: aDirectory
>   ^ aDirectory exists on: Error do: [  false ]
>
> And so, the above 4 methods should actually send 
> #directoryExistsAndValid:  rather than #directoryExists
>
I'm not sure that I want to try to bullet-proof this chunk of code ... I 
am worried about what happens if you don't have write permission in the 
first place or the disk is full or ???? there are too many possible 
error conditions that will either continue to fail or may mask the 
original problem if we just handle the errors ...

Besides it seems to me that the problem here is that 
MCGitBasedNetworkRepository class>>resetCacheDirectoryIfInvalid (which 
sets the cacheDirectory nil) won't work because if I understand things 
correctly `MCGitHubRepository cacheDirectory: nil` doesn't work ... or 
am I missing something here ....

Dale
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20151027/be36b1f1/attachment.html>


More information about the Glass mailing list