Closed khsrali closed 1 month ago
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.
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.
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:
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.
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?
Yes, we did not just consider it we pushed the change to support it :-) https://github.com/eth-cscs/firecrest/commit/a3b796e0fb665ba40e6d9b911ac54fd2f5f6c7e1
super! thanks a lot :)
Steps to reproduce:
remote/mydir
remote/mydir/myfile
mydir
and call it:remote/link_to_mydir
get_utilities_ls
forremote/link_to_mydir
Expected behavior:
the same as
ls
command, listmyfile
api version
unknown (see issue #204), I'm guessing
v1.16.0
is ondom
machine at the moment.