feat: add occ command files:list

[yemkareems]

Duplicate pr of #43342 since CI CD issues are there in the original PR
Possible usage example with params
occ files:list admin --path abc --sort name --order ASC --minSize 100 --maxSize 1008400 --type application

Sample usage

occ files:list admin

if path is not mentioned list all files in the root directory of the user

occ files:list admin --path abc

if path is mentioned list all files in the path mentioned alone

occ files:list admin --sort name --order ASC

occ files:list alice --path Media --sort size --order DESC

occ files:list admin --type image

occ files:list admin --type application --minSize 2750 --maxSize 148415

• Resolves: #

Summary

TODO

• ...

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)

[come-nc]

I’m not sure I understand the reasoning behind the path handling.

Would it not be better to have a user argument and a path argument inside this user folder?
Here it forces a path starting with a username, that feels unexpected. Did you try it with groupfolders and such?

[yemkareems]

I’m not sure I understand the reasoning behind the path handling.

Would it not be better to have a user argument and a path argument inside this user folder? Here it forces a path starting with a username, that feels unexpected. Did you try it with groupfolders and such?

@come-nc this was implemented similar to files:scan which had both user_id and path. Since user was extracted from the path it was omitted and path was made a required argument

[come-nc]

I’m not sure I understand the reasoning behind the path handling.
Would it not be better to have a user argument and a path argument inside this user folder? Here it forces a path starting with a username, that feels unexpected. Did you try it with groupfolders and such?

@come-nc this was implemented similar to files:scan which had both user_id and path. Since user was extracted from the path it was omitted and path was made a required argument

This is not the same thing, files:scan scans the disk folders so it’s limited to paths on the disk, but I expect files:list is expected to list files as in the UI, no? Otherwise people can use ls.

After discussing with the team:
I think we should go with having two arguments, userid and path.
Then you call getUserFolder($userId) on the root folder, and you can use get($path) on the userfolder instance.

[yemkareems]

path

I’m not sure I understand the reasoning behind the path handling.
Would it not be better to have a user argument and a path argument inside this user folder? Here it forces a path starting with a username, that feels unexpected. Did you try it with groupfolders and such?

@come-nc this was implemented similar to files:scan which had both user_id and path. Since user was extracted from the path it was omitted and path was made a required argument

This is not the same thing, files:scan scans the disk folders so it’s limited to paths on the disk, but I expect files:list is expected to list files as in the UI, no? Otherwise people can use ls.

After discussing with the team: I think we should go with having two arguments, userid and path. Then you call getUserFolder($userId) on the root folder, and you can use get($path) on the userfolder instance.

Did it as suggested. Now user is a mandatory argument and path may or may not be present. Used getUserFolder in place of get and then get is used on top of getUserFolder instance

[come-nc]

Suggested change

	"<error>Home storage for user $user not writable or 'files' subdirectory missing</error>"
	"<error>Home storage for user $user not readable or 'files' subdirectory missing</error>"

[come-nc]

Suggested change

	?string $path = "",
	string $path = "",

[come-nc]

Suggested change

	} catch (\Exception $e) {
	$output->writeln(
	"<error>Exception during list: " . $e->getMessage() . "</error>"
	);
	$output->writeln("<error>" . $e->getTraceAsString() . "</error>");
	}
	}

You can simply let unexpected exceptions bubble up, parent class takes care of showing the trace depending on verbosity if I recall correctly.

[come-nc]

Why all this?
This is the only command that do that to my knowledge.
Nextcloud already has an exception handler which logs them I think.

I suggest to remove this.