Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

get_utilities_ls doesn't return the content of a symlink path #205

Closed
khsrali opened this issue Jul 29, 2024 · 6 comments
Closed

get_utilities_ls doesn't return the content of a symlink path #205

khsrali opened this issue Jul 29, 2024 · 6 comments

Comments

@khsrali
Copy link

khsrali commented Jul 29, 2024

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
Copy link

theely commented Jul 31, 2024

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
Copy link
Author

khsrali commented Jul 31, 2024

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
Screenshot_20240731_195857

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
Copy link

theely commented Jul 31, 2024

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
Copy link
Author

khsrali commented Aug 5, 2024

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
Copy link

theely commented Aug 5, 2024

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

@khsrali
Copy link
Author

khsrali commented Aug 5, 2024

super! thanks a lot :)

@jpdorsch jpdorsch closed this as completed Aug 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants