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

find includes the parent folder name #799

Open
classner opened this issue Sep 23, 2023 · 4 comments
Open

find includes the parent folder name #799

classner opened this issue Sep 23, 2023 · 4 comments

Comments

@classner
Copy link

At least since version 2023.9 s3fs.S3FileSystem().find(...) includes the folder that it searches in. This is a breaking change with previous behavior and also possibly introduces bugs in the completely valid case of having a subfolder with the same name as the folder to search in, for example for exhaustive iteration.

@classner
Copy link
Author

This was introduced after 2023.5.0, it still behaves as expected (not including the additional folder name) on that version.

@martindurant
Copy link
Member

I believe we have been striving for consistency with posix commands, and find in a shell deos indeed also include the path matching the argument as an output.

@ianthomas23 , any comment?

@classner
Copy link
Author

Understood, and if consistency with posix is the goal that makes sense - it just broke some of our workflows because we relied on the old behavior. It'd be easy enough to filter for this case with a separate query, however if there was a flag that allowed to use either behavior within s3fs that would save the additional request and make it backwards compatible if required.

@ianthomas23
Copy link
Contributor

I think we have to stick with consistency with posix. I know we have made many backwards-incompatible changes in the last 6 months or so but they have all been to fix previously incorrect behaviour, and we have to accept that this will have annoyed users but it is best to correct problems as soon as possible.

We can't add flags to support previous behaviour. We would need CI to support both current and previous behaviour, and we don't have spare maintenance time to spend on this. If a given maintainer had an extra n hours to spend on fsspec then I would rather they spend it fixing current problems rather than supporting previous behaviour.

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