#2513 Creating relative links with "file link .." comman

obsolete: 8.4.4
open-fixed
7
2006-03-31
2003-10-31
No

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

Discussion

  • Vince Darley

    Vince Darley - 2003-10-31

    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.

     
  • Don Porter

    Don Porter - 2003-11-13
    • milestone: --> obsolete: 8.4.4
     
  • Vince Darley

    Vince Darley - 2003-12-11

    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?

     
  • Vince Darley

    Vince Darley - 2003-12-11

    Logged In: YES
    user_id=32170

    Please try the attached patch.

     
  • Hemang Lavana

    Hemang Lavana - 2003-12-11

    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.

     
  • Vince Darley

    Vince Darley - 2003-12-12

    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.

     
  • Hemang Lavana

    Hemang Lavana - 2003-12-12

    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

     
  • Vince Darley

    Vince Darley - 2003-12-12

    diff -u with windows eols

     
  • Vince Darley

    Vince Darley - 2003-12-12

    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).

     
  • Hemang Lavana

    Hemang Lavana - 2003-12-12

    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

     
  • Don Porter

    Don Porter - 2003-12-12

    Logged In: YES
    user_id=80530

    See Tcl Bug 747629.

     
  • Vince Darley

    Vince Darley - 2003-12-16

    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!

     
  • Hemang Lavana

    Hemang Lavana - 2003-12-16

    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.

     
  • Vince Darley

    Vince Darley - 2003-12-16
    • status: open --> closed-fixed
     
  • Vince Darley

    Vince Darley - 2003-12-16

    Logged In: YES
    user_id=32170

    Thanks -- all appears fine, as you say. I'll mark that test
    as nonPortable and close this.

     
  • Jeffrey Hobbs

    Jeffrey Hobbs - 2004-02-06
    • priority: 5 --> 8
    • status: closed-fixed --> open-fixed
     
  • Jeffrey Hobbs

    Jeffrey Hobbs - 2004-02-06

    Logged In: YES
    user_id=72656

    Reopening for 8.4.6 backport.

     
  • Don Porter

    Don Porter - 2004-12-15
    • summary: Creating relative links with "file link .." command? --> Creating relative links with "file link .." comman
     
  • Don Porter

    Don Porter - 2004-12-15

    Logged In: YES
    user_id=80530

    this was never backported?

     
  • Matthias Kraft

    Matthias Kraft - 2005-07-29

    Logged In: YES
    user_id=330806

    Are there any plans to backport this into 8.4? I would
    really need it there!

    -- Matthias Kraft

     
  • Don Porter

    Don Porter - 2006-03-10
    • priority: 8 --> 9
     
  • Don Porter

    Don Porter - 2006-03-10

    Logged In: YES
    user_id=80530

    Getting this backported for 8.4.13
    would be really nice. I realize it's
    a tall order...

     
  • Don Porter

    Don Porter - 2006-03-31
    • priority: 9 --> 7
     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks