feat(posixfs): #3182 add basepath option in the "posixfs scan" command

[pbleser-oc]

Description

• add support for specifying a set of resources when running the posixfs scan command scanning, or a singular file to scan, as opposed
• refactors the resource walking function implemented in Extend posixfs consistency check #3220 in order to reuse it for the posixfs scan command

Related Issue

• implements Implement subtree scanning in "posixfs scan" #3182
• documentation: feat(docs): add documentation for the posixfs scan command docs#1084

Motivation and Context

Addresses use-cases where files are copied into the PosixFS storage directory tree while the server is not running or with collaborative mode disabled, e.g. during large migrations or in disaster recovery scenarios.

With these changes, it is possible to perform the storage scanning in a much more granular way, which may help in cases where the storage tree is especially large and scanning everything would be too slow.

How Has This Been Tested?

Has been tested locally/manually by

• running the server with collaborative mode disabled (STORAGE_USERS_POSIX_WATCH_FS=false)
• copying files into a space storage directory, cp ... ~/.opencloud/storage/users/projects/9c4feaa1-0a8f-4f9d-bcf7-2d79b714d9d5/
• checking that no xattrs were set on those files using getfattr -d
• running the posixfs scan command with different use-cases:
  • on the storage root
  • without arguments
  • on a subdirectory of a space
  • on the space directory
  • on individual files
• and then checking that the xattrs were set (user.oc.id, user.oc.parentid, etc...), again using getfattr -d

Unfortunately, it is not possible to add unit tests as it would require a lot of changes to abstract away the filesystem operations, or a significant amount of test harness setup to be able to run the command with a NATS Jetstream and everything else that is needed for it.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Technical debt
• Tests only (no source changes)

Checklist:

• Code changes
• Unit tests added
• Acceptance tests added
• Documentation added

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 24 complexity · 0 duplication

Metric	Results
Complexity	24
Duplication	0

View in Codacy

🟢 Coverage 0.00% diff coverage

Metric	Results
Coverage variation	Report missing for 19e44f91
Diff coverage	✅ 0.00% diff coverage

View coverage diff in Codacy

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (19e44f9)	Report Missing	Report Missing	Report Missing
Head commit (6663fbe)	84009	19254	22.92%

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details

	Coverable lines	Covered lines	Diff coverage
Pull request (#3235)	173	0	0.00%

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

¹ Codacy didn't receive coverage data for the commit, or there was an error processing the received data. Check your integration for errors and validate that your coverage setup is correct.

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}