1. Forum
  2. Usenet
  3. COMP.LANG.TCL

  • Is there a blind spot in file attributes?

    From Luc@21:1/5 to All on Mon Dec 18 21:53:08 2023
    I just found out something interesting about file attributes and broken symlinks. The file command can't read them at all.

    file attributes symlinkfile -owner

    It's interesting because it tries to go straight to the linked file even
    though I never told it to with readlink. It doesn't seem to care about
    the symlink file.

    That makes sense and I even find it convenient when trying to determine
    whether it's a directory, for example. It doesn't care about the link,
    it just looks at the target and saves me an extra step.

    But the user may want to delete the link because it's no longer valid,
    it's a broken link, in which case it may be good to see who the owner
    is.

    When checking for mtime, the file command also gets the date and time
    of the target, not the link. I happen to like that behavior better,
    but I can't figure out how to obtain the information on the symlink file specifically in case I need it. When was that symlink created (which is
    very likely the same date and time as mtime)? It seems I can't extract
    that information with Tcl.

    The other file manager I have here (SpaceFM) treats a symlink like a
    regular file, except that it displays the target file in the status bar.
    For everything else, the target is ignored. Like I said, I often find
    the Tcl way better, but what if I want or need the other way?

    Is there a way?

    --
    Luc


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rich@21:1/5 to Luc on Tue Dec 19 01:31:01 2023
    Luc <luc@sep.invalid> wrote:
    I just found out something interesting about file attributes and broken symlinks. The file command can't read them at all.

    file attributes symlinkfile -owner

    It's interesting because it tries to go straight to the linked file even though I never told it to with readlink. It doesn't seem to care about
    the symlink file.

    You are not seeing the full picture. It is libc/the kernel that does
    not care. Unless you use the correct libc calls, accessing a symlink
    always accesses the file to which the symlink points.

    That makes sense and I even find it convenient when trying to determine whether it's a directory, for example. It doesn't care about the link,
    it just looks at the target and saves me an extra step.

    If you do want ifo about the link itself, you need to use lstat to get
    the symlink info.

    But the user may want to delete the link because it's no longer valid,
    it's a broken link, in which case it may be good to see who the owner
    is.

    That is what the lstat subcommand to file is meant for, to get the info
    on the "link" rather than the file to which it points.

    When checking for mtime, the file command also gets the date and time
    of the target, not the link. I happen to like that behavior better,
    but I can't figure out how to obtain the information on the symlink file specifically in case I need it.

    lstat -- it is right there in the docs.

    When was that symlink created (which is very likely the same date and
    time as mtime)? It seems I can't extract that information with Tcl.

    No, you can, you just have to ask the right way, with lstat.

    Is there a way?

    Yes, see above.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)