[ python-Bugs-763708 ] Failures in test_macostools for --enable-unicode=ucs4

Fri Jun 1 09:23:56 CEST 2007

Bugs item #763708, was opened at 2003-07-01 08:54
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763708&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Macintosh
Group: Python 2.3
Status: Open
Resolution: Later
Priority: 4
Private: No
Submitted By: Brett Cannon (bcannon)
Assigned to: Jack Jansen (jackjansen)
Summary: Failures in test_macostools for --enable-unicode=ucs4

Initial Comment:
Here are the test results:

test_copy (__main__.TestMacostools) ... ok
test_mkalias (__main__.TestMacostools) ... ERROR
test_mkalias_relative (__main__.TestMacostools) ... ERROR
test_touched (__main__.TestMacostools) ... ok

=====================================
=================================
ERROR: test_mkalias (__main__.TestMacostools)
--------------------------------------------------------------------
--
Traceback (most recent call last):
  File &quot;Lib/test/test_macostools.py&quot;, line 69, in test_mkalias
    macostools.mkalias(test_support.TESTFN, TESTFN2)
  File &quot;/Users/drifty/cvs_code/lib/python2.3/plat-mac/
macostools.py&quot;, line 46, in mkalias
    File.FSGetResourceForkName())
Error: (-1402, 'Fork name parameter is bad')

=====================================
=================================
ERROR: test_mkalias_relative (__main__.TestMacostools)
--------------------------------------------------------------------
--
Traceback (most recent call last):
  File &quot;Lib/test/test_macostools.py&quot;, line 78, in 
test_mkalias_relative
    macostools.mkalias(test_support.TESTFN, TESTFN2, 
sys.prefix)
  File &quot;/Users/drifty/cvs_code/lib/python2.3/plat-mac/
macostools.py&quot;, line 46, in mkalias
    File.FSGetResourceForkName())
Error: (-1402, 'Fork name parameter is bad')

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2007-06-01 09:23

Message:
Logged In: YES 
user_id=45365
Originator: NO

Hi Brett!
This bug turns in to a once-a-year "how are you " conversation:-)

I haven't checked whether unicode objects have grown the required method
in the mean time. If they have this problem could be solved, otherwise it
can't (at least, not without serious hacking).
But: even if the APIs are available that woulnd't mean that I have time to
look at the problem in the foreseeable future...

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2007-06-01 00:49

Message:
Logged In: YES 
user_id=357491
Originator: YES

This is still failing in the trunk (r55677).  Any chance this is going to
be addressed soon?

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2004-12-19 01:21

Message:
Logged In: YES 
user_id=45365

I'd like to keep this bug open, because the underlying problem is serious:

the Python interfaces to the MacOSX APIs assume that the binary 
representation of "python unicode" is identical to the binary 
representation of "macosx unicode". This needs to be fixed at some 
point, but such a fix requires major surgery (especially if we want things

to be efficient for the normal case, where the assumption indeed holds).

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-12-18 22:40

Message:
Logged In: YES 
user_id=357491

This test still fails in 2.4 and so far in 2.5 .  Does this still deserve
a 
"later" resolution?

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-07-22 23:27

Message:
Logged In: YES 
user_id=357491

Sorry, Jack.  I didn't know that this was a Unicode issue.  Oh well, 
at least the cause has been narrowed down.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-07-22 21:35

Message:
Logged In: YES 
user_id=45365

Boo, hiss! :-)

You're using --enable-unicode=ucs4 and you didn't tell me that 
when there's a unicode problem:-)

My guess is that I'm somewhere grabbing the pointer from the 
Python unicode object and passing that straight to the Apple 
routines, which will fail miserably because they expect ucs2 (or 
utf16, or whatever it's called). Actually, I wouldn't be surprised if 
there are more places where I do that. Yes, looking at the data 
returned this looks like a very likely scenario.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-07-22 20:42

Message:
Logged In: YES 
user_id=357491

The Carbon.File.FSGetResourceForkName() returns 
u'\U00520045\U0053004f\U00550052\U00430045\U005f0046\U004f
0052\U004b0000\U0001bfff\Uf4100000\U00080040\Ue4589000\U5
334bfff\Uf4200000' .  That can't be printed because of a 
conversion to ASCII error.  If I remember correctly this is what 
was returning the string &quot;ERROR&quot; (or however it was formatted). 

There is also the ``Error: (-1402, 'Fork name parameter is bad'`` 
from the failed tests.

And here is the info you wanted, Jack:

1. My build has the settings --with-pydebug --prefix=$HOME/
cvs_code --enable-ipv6 --enable-unicode=ucs4 ; so it's a straight 
build.
2. I think so.  I also have an OS 9 partition that came with my 
iBook that I never touch.
3. Nope, no stray TESTFN files.  The  only file I have in my CVS 
directory that is not in the repository is Lib/plat-mac/
errors.rsrc.df.rsrc .

Hope that helps.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-07-22 17:22

Message:
Logged In: YES 
user_id=45365

Brett, please try the following:
&gt;&gt;&gt; import Carbon.File
&gt;&gt;&gt; Carbon.File.FSGetResourceForkName()
u'RESOURCE_FORK'
&gt;&gt;&gt; 

You mention it prints ERROR for you, I'd like to see exactly what it 
prints (u&quot;ERROR&quot;? &quot;ERROR&quot;? ERROR?).

And a bit more information I need to try and duplicate the 
problem:
1. Are you using a framework build or a straight build?
2. Is your /Users/drifty directory in yoor root partition?
3. Could you check that there are no test_support.TESTFN or 
test_support.TESTFN + '2' turds on your system?

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-07-22 08:48

Message:
Logged In: YES 
user_id=357491

Tested and still fails with a CVS update on 2003-07-21.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-07-20 02:30

Message:
Logged In: YES 
user_id=45365

This seems to be fixed in 2.3c1. Could you please test?

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-07-09 20:03

Message:
Logged In: YES 
user_id=357491

OK, so the problem seems to be coming from Mac/Modules/file/
_Filemodule.c and the File_FSGetResourceForkName function 
(printing the result just prints &quot;ERROR&quot;).  The online docs for

FSGetResourceForkName (which is pretty much all that is called in 
that function) can be found at http://developer.apple.com/
documentation/Carbon/Reference/File_Manager/file_manager/
function_group_20.html#//apple_ref/c/func/
FSGetResourceForkName .

Now it looks like the error is an OS X error and has nothing to do 
with Python.  The error (-1402) means that the fork name is 
syntactically invalid.  I don't see how this can mean anything, 
though, since FSGetResourceForkName's only argument is a 
pointer to store the result of the call into.

The  only thing I can think of that might be causing this error from 
Python's side is that a resource fork does not exist when the call is 
made.  But this is just a guess so I could be wrong.

Jack, I am going to be gone from July 13 until July 21, so if  you 
need any debugging info from me before 2.3 final goes out I am 
afraid it will have to happen soon.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-07-01 22:42

Message:
Logged In: YES 
user_id=357491

OK, Jack, here is your info:
  - 10.2.6
  - Python 2.3b2+ straight from CVS (only way to code =)
  - HFS+ I believe (Finder says my HD is Mac OS Extended)

Ran the test from my CVS tree with my installed version of Python 
2.3b2+ (I can't do anything the standard way).  I just ran it with 
the installed copy from the installed test directory and got the 
errors.  I also just ran it with the compiled copy but not installed 
Python executable in my CVS tree and once again got the error.

I noticed this came up, for me at least, when I was checking a 
patch for posixpath.py (which was applied to CVS).  I checked the 
code, though, and didn't find a problem where anything changed to 
posixpath.py would affect it.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2003-07-01 13:47

Message:
Logged In: YES 
user_id=45365

Brett, I've seen this bug once in a while, but whenever I try to 
hunt it it disappears. Could you give me the following info:
- OSX exact version
- Python exact version, plus where you got it from (binary install, 
source tarball install, CVS)
- Type of filesystem (HFS+, UFS, NFS, something else)

Also, if you're building from source, did you run the tests from the 
build tree or from the installed tree? Could you try the other one 
too?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=763708&group_id=5470