From: SourceForge.net <no...@so...> - 2004-04-21 13:38:49
|
Bugs item #929534, was opened at 2004-04-04 22:43 Message generated for change (Comment added) made by tauvan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=929534&group_id=10894 Category: 36. File System Group: current: 8.4.6 Status: Open Resolution: None Priority: 5 Submitted By: tauvan (tauvan) Assigned to: Jim Ingham (wolfsuit) Summary: OS X: filesystem FAILED link normalisation Initial Comment: filesystem-1.2 FAILED filesystem-1.3 FAILED filesystem-1.4 FAILED filesystem-1.7 FAILED filesystem-1.9 FAILED filesystem-1.10 FAILED filesystem-1.11 FAILED these occur both local and root You can see more detailed description under 20 failures bug machine: mac ppc G4 (1st PCI 400Mhz) OSX 10.1.5 My solution attempt at trying to be helpfull attached but needs to be "Tcl compatable" However, since I'm trying if I have questions "not bugs" where do I go? ---------------------------------------------------------------------- >Comment By: tauvan (tauvan) Date: 2004-04-21 08:38 Message: Logged In: YES user_id=1011552 Maybe I phrase wrong? The path to normalize entering TclpObjNormalizePath is "/Users/ steven/Desktop/tclmyproj/tcl8.4.6/macosx/build/gorp.file/foo". At that instant it is passed there is a "/Users/steven/Desktop/ tclmyproj/tcl8.4.6/macosx/build/gorp.file", but my new code errors on "/Users/steven/Desktop/tclmyproj/tcl8.4.6/macosx/build/gorp.file/ foo" exits with error "ENOTDIR" because gorp.file is not a directory. It returns a NULL string with startAt of 53. It is then passed "/Users/ steven/Desktop/tclmyproj/tcl8.4.6/macosx/build/link.file/foo" exiting "ENOTDIR" with NULL and startAt of 53. So I am trying to be sure of what is being requested a that precise instant in the program. Is it supposed to return "/Users/steven/ Desktop/tclmyproj/tcl8.4.6/macosx/build/gorp.file/foo" possibily allowing someone to try an operation on that file? If gorp.file was a directory and link.file a directory it passes, hence, should I be passing a string ignoring the information found and/or what should be the startAt? ---------------------------------------------------------------------- Comment By: Vince Darley (vincentdarley) Date: 2004-04-21 02:09 Message: Logged In: YES user_id=32170 As you say, you're better off trying to create a replacement for realpath, since the rest of the code is known to work ok. As for: [file normalize [file join gorp.file foo]] Well, file join will return gorp.file/foo, and that must then be normalized partly by other functions and partly by the code you're trying to write. You probably want to read the documentation of 'file join'... I don't see how the code that you write should even notice whether it's being given: file normalize gorp.file/foo or file normalize [file join gorp.file/foo] Since your code is only inside the 'file normalize' routines.... Anyway, 'file join' is very well documented (more so than we can explain here is a few lines), so please do read that, and good luck with the Realpath implementation. ---------------------------------------------------------------------- Comment By: tauvan (tauvan) Date: 2004-04-20 22:34 Message: Logged In: YES user_id=1011552 Hi I was doing some testing, I haven't mention the code I sent you has one small bug, but it tests identical to tests with using realpath, except for startAt return value. Now, I created new code that handles exceptions, a realpath replacement, and luckily got some FAILS. So I need some clarifaction on what the tests are asking or what join is permitted to do. As an example (from test filesystem-1.2): [file normalize [file join gorp.file foo]] questions: should grop.file be turned into a dir to yield gorp.file/foo? : if gorp.file is turned into a dir is link still valid? : should it be gorp.filefoo? :am I just loonie? my return values from TclpObjNormalizePath show ....../gorp.file/foo Thanks ---------------------------------------------------------------------- Comment By: tauvan (tauvan) Date: 2004-04-20 08:58 Message: Logged In: YES user_id=1011552 Not sure if this helps, but as tcl is mentioned on a list of realpath users BSD issued a notice about a security issue, and the new realpath mentions something about thread safe. ---------------------------------------------------------------------- Comment By: Daniel A. Steffen (das) Date: 2004-04-20 02:14 Message: Logged In: YES user_id=90580 sorry for the delay this a known problem with threaded tcl on OSX; the OSX realpath is not threadsafe (it uses chdir internally and the current dir is process global...), so we've had to disable it in the threaded build: 2003-05-13 Daniel Steffen <da...@us...> * unix/tclUnixPort.h: worked around the issue of realpath() not being thread-safe on Mac OS X by defining NO_REALPATH for threaded builds on Mac OS X. [Bug 711232] see https://sourceforge.net/tracker/? func=detail&atid=110894&aid=711232&group_id=10894 at the time, Zoran said he'd submitted a bugreport with Apple about this, don't know the current status of that though; Jim? to fix this in tcl, TclpObjNormalizePath() would need to be implemented properly for systems without realpath /* * We should really now convert this to a canonical path. We do * that with 'realpath' if we have it available. Otherwise we could * step through every single path component, checking whether it is a * symlink, but that would be a lot of work, and most modern OSes * have 'realpath'. */ (in fact realpath on OSX does exactly this, but in an thread-unsafe manner...) or we could add a crossplatform realpath() to compat. tauvan, for questions that are "not bugs" use the tcl-mac mailing list: https://lists.sourceforge.net/lists/listinfo/tcl-mac ---------------------------------------------------------------------- Comment By: Vince Darley (vincentdarley) Date: 2004-04-08 04:15 Message: Logged In: YES user_id=32170 This is somewhat beyond me, but I think Daniel will be able to shed some light (when he gets back from cycling next week ;-). ---------------------------------------------------------------------- Comment By: tauvan (tauvan) Date: 2004-04-08 02:21 Message: Logged In: YES user_id=1011552 Sorry to do this but I just found so new data that may or may not just make this a OSX issue. In trying to gather more info on another bug, I had this idea of doing a straight unix build, not using macosx makefile nor my build system. Well I accedently forgot to "--enable-threads". After running the tests, I noticed there was not 27 failures. All fileSystem failures disappeared. I then ran "--enable-threads" they appeared. Then, tried without enabled again, disappeared. I also verified that the test did not skip because of testthread. I only ran this as local user, but thought I should pass this on immediatly, because it changes things. ---------------------------------------------------------------------- Comment By: tauvan (tauvan) Date: 2004-04-05 09:38 Message: Logged In: YES user_id=1011552 ac_cv_func_realpath=${ac_cv_func_realpath=yes} However, in tclUnixPort.h; #ifdef MAC_OSX_TCL /* * On Mac OS X, realpath is currently not * thread safe, c.f. SF bug # 711232. */ #define NO_REALPATH #endif ---------------------------------------------------------------------- Comment By: Vince Darley (vincentdarley) Date: 2004-04-05 03:58 Message: Logged In: YES user_id=32170 Thanks for the report -- we'll look into these. The first thing that occurs to me is whether 'realpath' is supported or not on OS X 10.1.5. Anyway, if you have questions, either comp.lang.tcl or the mac-tcl mailing list is the place. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=929534&group_id=10894 |