From: SourceForge.net <no...@so...> - 2003-12-16 15:08:35
|
Bugs item #833713, was opened at 2003-10-31 10:34 Message generated for change (Comment added) made by hemanglavana You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=833713&group_id=10894 Category: 36. File System Group: obsolete: 8.4.4 Status: Open Resolution: None Priority: 5 Submitted By: Hemang Lavana (hemanglavana) Assigned to: Vince Darley (vincentdarley) Summary: Creating relative links with "file link .." command? Initial Comment: When I create symbolic links (on solaris and linux, tcl8.4.4) using [file link -symbolic ...] command, the created link file always points to an absolute path even when a relative path is specified. This is causing problems when the directory is moved around and the links have to be deleted and re-created. Is this the correct behavior (dictated by cross-platform support)? It would be nice if the [file link] command behaved like the unix 'ln' utility in this respect so that I don't have to invoke [exec ln -s ...] for creating relative links. Hemang. ----------------------------- I don't see that this is specifically mentioned anywhere in the docs of the implementation. It seems a byproduct of the Tcl_FSGetNativePath request returning a fully qualified path. I'm not sure whether this is a bug, so I've cc'ed the implementor, Vince Darley. Jeff Hobbs ---------------------------------------------------------------------- >Comment By: Hemang Lavana (hemanglavana) Date: 2003-12-16 10:08 Message: Logged In: YES user_id=81875 This is on solaris 2.8. godel:144> /tmp/hlavana/tcltk/bin/tclsh8.5 % info patch 8.5a0 % file mkdir td1 % set dir [pwd] /tmp/hlavana % cd td1 % set f1 [file normalize [file join .. td1]] /tmp/hlavana/td1 % set f2 [file normalize [file join .. td2]] /tmp/hlavana/td2 % file join .. td1 ../td1 % file join .. td2 ../td2 % file rename [file join .. td1] [file join .. td2] % pwd /tmp/hlavana/td2 % file rename [file join .. td2] [file join .. td3] % pwd /tmp/hlavana/td3 % It seems that it is possible to change the name of the current directory on solaris platforms. ---------------------------------------------------------------------- Comment By: Vince Darley (vincentdarley) Date: 2003-12-16 05:37 Message: Logged In: YES user_id=32170 Can you tell me what 'file norm [file join .. td1]' and 'file norm [file join .. td1x]' give at this point in the test suite? Do they appear to be correct? What is '$dir' in this test? thanks! ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2003-12-12 18:28 Message: Logged In: YES user_id=80530 See Tcl Bug 747629. ---------------------------------------------------------------------- Comment By: Hemang Lavana (hemanglavana) Date: 2003-12-12 13:36 Message: Logged In: YES user_id=81875 Okay, I tried option (b) and now I get only one error: fCmd.test ==== fCmd-9.14.2 file rename: comprehensive: dir into self FAILED ==== Contents of test case: cleanup file mkdir td1 set dir [pwd] cd td1 set res [list [catch {file rename [file join .. td1] [file join .. td1x]} ms g] $msg] cd $dir set res ---- Result was: 0 {} ---- Result should have been (exact matching): 1 {error renaming "../td1" to "../td1x": permission denied} ==== fCmd-9.14.2 FAILED ---------------------------------------------------------------------- Comment By: Vince Darley (vincentdarley) Date: 2003-12-12 12:17 Message: Logged In: YES user_id=32170 Hmm -- I'll have to think about those. I've updated fileSystem.test to be more informative. Could you please re-run the tests with those changes in place? (either (a) just update fileSystem.test from cvs and re-run, or (b) update everything from cvs then apply the patch attached to this report and re-run). ---------------------------------------------------------------------- Comment By: Hemang Lavana (hemanglavana) Date: 2003-12-12 12:05 Message: Logged In: YES user_id=81875 I am seeing some failures on solaris2.8 with your patch applied to cvs head: fCmd.test ==== fCmd-9.14.2 file rename: comprehensive: dir into self FAILED ==== Contents of test case: cleanup file mkdir td1 set dir [pwd] cd td1 set res [list [catch {file rename [file join .. td1] [file join .. td1x]} ms g] $msg] cd $dir set res ---- Result was: 0 {} ---- Result should have been (exact matching): 1 {error renaming "../td1" to "../td1x": permission denied} ==== fCmd-9.14.2 FAILED fileSystem.test ==== filesystem-1.7 link normalisation FAILED ==== Contents of test case: string equal [file normalize [file join dir.link linkinside.file foo]] [file normalize [file join dir.file inside.file foo]] ---- Result was: 0 ---- Result should have been (exact matching): 1 ==== filesystem-1.7 FAILED ==== filesystem-1.9 link normalisation FAILED ==== Contents of test case: file delete -force dir.link file link dir.link [file nativename dir.file] string equal [file normalize [file join dir.file linkinside.file foo]] [fil e normalize [file join dir.link inside.file foo]] ---- Result was: 0 ---- Result should have been (exact matching): 1 ==== filesystem-1.9 FAILED ==== filesystem-1.10 link normalisation: double link FAILED ==== Contents of test case: file link dir2.link dir.link string equal [file normalize [file join dir.file linkinside.file foo]] [fil e normalize [file join dir2.link inside.file foo]] ---- Result was: 0 ---- Result should have been (exact matching): 1 ==== filesystem-1.10 FAILED ==== filesystem-1.11 link normalisation: double link, back in tree FAILED ==== Contents of test case: file link [file join dir2.file dir2.link] dir2.link string equal [file normalize [file join dir.file linkinside.file foo]] [fil e normalize [file join dir2.file dir2.link inside.file foo]] ---- Result was: 0 ---- Result should have been (exact matching): 1 ==== filesystem-1.11 FAILED ---------------------------------------------------------------------- Comment By: Vince Darley (vincentdarley) Date: 2003-12-12 04:52 Message: Logged In: YES user_id=32170 Could you try this updated patch? -- it fixes the ~user issue and also patches some generic normalization code so that it can handle these relative links. It would be very helpful if you could run the file*.test tests after applying this patch. ---------------------------------------------------------------------- Comment By: Hemang Lavana (hemanglavana) Date: 2003-12-11 12:49 Message: Logged In: YES user_id=81875 On unix systems, "~/foo" is first expanded by the shell before passing it onto the link command. So such files will have absolute paths, see below: godel:271> ln -s ~/foo bar godel:272> ls -l bar lrwxrwxrwx 1 hlavana eng 18 Dec 11 10:20 bar -> /users/hlavana/foo godel:273> I have verified that your patch work correctly for relative links. As for the ~ chars, it should expand into absolute paths, otherwise on unix the link is not created properly: hlavana-u5:165> ./tcltk/bin/tclsh8.4 % file link -symbolic foo ~/ddts ~/ddts % cat foo cat: cannot open foo child process exited abnormally % file exists foo 0 % file exists ~/ddts 1 % exit hlavana-u5:166> ls -l foo lrwxrwxrwx 1 hlavana eng8 6 Dec 11 12:41 foo -> ~/ddts hlavana-u5:167> cat foo cat: cannot open foo hlavana-u5:168> As you can see, ~/ddts is a valid file but foo not exist. ---------------------------------------------------------------------- Comment By: Vince Darley (vincentdarley) Date: 2003-12-11 06:29 Message: Logged In: YES user_id=32170 Please try the attached patch. ---------------------------------------------------------------------- Comment By: Vince Darley (vincentdarley) Date: 2003-12-11 05:59 Message: Logged In: YES user_id=32170 I'll set about fixing this, but first a question. Is a symbolic link on Unix effectively just a link to an arbitrary 'string' or is some pre-processing done first? For example, what should: % file link -symbolic foo ~vince do? Should it genuinely link to '~vince' or should it first expand '~vince' and link to the expanded version? ---------------------------------------------------------------------- Comment By: Vince Darley (vincentdarley) Date: 2003-10-31 10:42 Message: Logged In: YES user_id=32170 It's hard to say if this is a bug or a feature. On balance (for Unix) I suppose it is a bug. The solution is to modify TclpObjLink's creation of 'target': CONST char *target = Tcl_FSGetNativePath(toPtr); so that it just uses 'Tcl_GetString' and a manual Tcl_UtfToExternal conversion. I don't know if Windows/MacOS support such relative links or not. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=833713&group_id=10894 |