get_utilities_ls doesn't return the content of a symlink path

[khsrali]

Steps to reproduce:

• make a directory remote/mydir
• touch a file in that directory remote/mydir/myfile
• in the parent directory make a link targeting mydir and call it: remote/link_to_mydir
• send a request get_utilities_ls for remote/link_to_mydir
• result is empty.

Expected behavior:

the same as ls command, list myfile

api version

unknown (see issue #204), I'm guessing v1.16.0 is on dom machine at the moment.

[theely]

Hi @khsrali,
thanks for reporting this. Firecrest's utilities/ls end-point behaves like the linux ls command.
Be aware that ls remote/link_to_mydir produces a different result than remote/link_to_mydir/.
In the first instance ls will describe the symbolic link in the second instance ls will list the files within the folder the symbolic link is pointing to.

I have tested your scenario with and without trailing / and as expected obtained the following responses:

/utilities/ls?targetPath=/home/service-account-firecrest-sample/tt_link

{ "description": "List of contents", "output": [ { "group": "root", "last_modified": "2024-07-31T16:19:42", "link_target": "tt", "name": "/home/service-account-firecrest-sample/tt_link", "permissions": "rwxrwxrwx", "size": "2", "type": "l", "user": "root" } ] }

/utilities/ls?targetPath=/home/service-account-firecrest-sample/tt_link/

{ "description": "List of contents", "output": [ { "group": "root", "last_modified": "2024-07-31T16:19:28", "link_target": "", "name": "myfile", "permissions": "rw-r--r--", "size": "0", "type": "-", "user": "root" } ] }

Hope this helps to clarify the utilities/ls endpoint behaviour.

[khsrali]

Hi @theely
Thanks for your answer, while I understand the logic of this design:
Still, it is not the same behaviour of what one would expect from a ls command

Right now, it's paradoxical. if you do /utilities/ls for a real directory without trailing /, remote/mydir returns it's content and doesn't describe mydir.

While intuitively, a uniform interface is expected. /utilities/ls shall behave the same in either case: the input is a link to a directory or it is a directory. Just as the ls command does.

Also please notice the response: { "description": "List of contents", I really expect this endpoint list content of link_to_mydir for me, with or without trailing / as it does for a normal directory.
Having or not having / is not an ideal way to describe a symlink.

[theely]

The guiding design principle for the /utilities/ls endpoint is that it should behave exactly like the linux ls command.

To further explain how the /utilities/ls endpoint behaves you should know that it is always executed running a ls -l [target_path] command. To reproduce the same behaviour in your tests you should always add the -l option.

What we expect is that:

• ls -l [folder] = folder content
• ls -l [folder]/ = folder content
• ls -l [link] = link description
• ls -l [link]/ = content of the linked folder

Based on my test the /utilities/ls endpoint does indeed produce the expected output.

What exactly is the use-case you are after? Is there a set of ls command options that produces the result you are expecting? I suspect what you are after is the "follow symbolic links" option (e.g. ls -lRL) which is currently not supported by firecrest.

[khsrali]

Alright, sorry, I didn't notice /utilities/ls is always executing ls -l.
Yes, the use case is to follow symbolic links.
Would you consider it for development?

[theely]

Yes, we did not just consider it we pushed the change to support it :-)
a3b796e

[khsrali]

super! thanks a lot :)