[Grok-dev] Re: Grokinstallation corrupts when editing source remotely over AFP

Philipp von Weitershausen philipp at weitershausen.de
Wed Jun 11 18:31:46 EDT 2008


Martijn Faassen wrote:
> Sebastian Ware wrote:
>> I edited app.py, adding some simple arithmetic to an update method 
>> (the first three lines):
>>
>>       def update(self):
>>         a= 1
>>         b = 2
>>         c = a + b
>>         protoncms.protonbase.ProtonEdit.update(self)
>>
>> Macintosh:/Volumes/PsycadeliaRAID/groklive/Tester grandvinumserver$ 
>> bin/zopectl fg
>> /Volumes/PsycadeliaRAID/groklive/Tester/parts/app/runzope -C 
>> /Volumes/PsycadeliaRAID/groklive/Tester/parts/zopectl/zope.conf
>> ***** Original name: 'tester.._app'
> 
> Hm, okay, so the double-dot theory is the correct one. Somehow in 
> grok_module, module_info.dottedname contains two dots instead of one.
> 
> Is it conceivable that your editor creates dotted names for temporary 
> file names? (perhaps backup files?). I.e. that there are times when a 
> "._app.py" file exists in your directory (besides "_app.py"?)?

Files like ._app.py are a general MacOSXism. AFAIK they contain the 
resource fork of files (which are something like metadata) on 
filesystems that don't allow files to have resource forks associated 
with them (e.g. FAT32, which means you'll commonly find them on USB 
sticks that were written by a Mac). Apparently AFP mounted volumes is 
among those filesystems as well.

> If so, I suspect the problem can be fixed in scan.py, in the method 
> 'getSubModuleInfos'.
> 
> There's a for loop there:
> 
>   for entry in sorted(os.listdir(directory)):
> 
> if you add as the first line in that loop the following:
> 
>    if entry.startswith('.'):
>        continue
> 
> that might fix matters. Should be safe enough to add this to Martian, as 
> Python modules aren't supposed to start with a dot.
> 
> In fact, module names have to start with an alphabetic character or an 
> underscore, so we can expand this rule to the following:
> 
>    if not entry[0].isalpha() and entry[0] != '_':
>        continue
> 
> could you test the latter and see whether that fixes your problem? If so 
> we can add the fix to Martian.

Yup, including a test with some of those MacOSX generated resource fork 
files :).

> I guess we could even expand this to 
> testing with a regular expression whether it's a valid Python module 
> name at all...

Not such a bad idea.



More information about the Grok-dev mailing list