Skip to content
This repository was archived by the owner on Jun 15, 2026. It is now read-only.

Fix infinite loop in directory discovery#53

Open
manu-crealytics wants to merge 1 commit into
Othoz:masterfrom
manuteleco:fix_dir_blob_creation
Open

Fix infinite loop in directory discovery#53
manu-crealytics wants to merge 1 commit into
Othoz:masterfrom
manuteleco:fix_dir_blob_creation

Conversation

@manu-crealytics

Copy link
Copy Markdown

The fix_storage method enters an infinite loop when there are other directories that have root_path as prefix.

For example, if the contents of the bucket look like this:

gs://mybucket/abc/file.txt
gs://mybucket/abc123/file.txt

this code results in an infinite loop:

from fs import open_fs
open_fs("gs://mybucket/abc?strict=False").fix_storage()

In order to avoid this, we need to ensure root_path has a trailing "/", when listing blobs, which prevents "abc123/file.txt" from being listed as child of "abc".

Additionally, Bucket.list_blobs was deprecated in favor of Client.list_blobs (see reference documentation).


Grüße aus Berlin

@manu-crealytics

Copy link
Copy Markdown
Author

Hi again. I see this PR was approved really quick but has remain unmerged for almost two months. Please, let me know if there is anything else I should do for this fix to be integrated in master and released. Looking forward to have this fixed upstream.

@trendelkampschroer

Copy link
Copy Markdown
Contributor

@manu-crealytics sorry for not following up on your contribution. It seems that the CI build on this PR never completed. Would you be so kind as to re-trigger CI by pushing an empty commit to your branch and check for the status of the CI. Once this is green we can proceed with merging your PR.
Thanks a lot for your contribution.

@manuteleco manuteleco force-pushed the fix_dir_blob_creation branch from 5eb431f to 3789f49 Compare May 12, 2023 07:30
@manu-crealytics

Copy link
Copy Markdown
Author

Sorry, this time it was me not responding promptly.

I've force-pushed the same commit, hoping that's enough to automatically trigger a build. Still, it doesn't seem to do anything.

When I visit https://app.travis-ci.com/github/Othoz/gcsfs/builds, I see a banner on top and with red background that reads:

We are unable to start your build at this time. You exceeded the number of users allowed for your plan. Please review your plan details and follow the steps to resolution.

If the problem is that the current plan in Travis doesn't allow any additional user (me) to trigger builds, the obvious fix could be changing/upgrading the plan.

But, as short term solution, it would be totally fine by me if you decide to close my PRs (this one and #54) and re-open them yourself. Here I am assuming that your user account is allowed to trigger Travis builds, while mine isn't.

Let me know what you think and whether there is anything else I can do. Thanks.

The `fix_storage` method enters an infinite loop when there are other
directories that have `root_path` as prefix.

For example, if the contents of the bucket look like this:
```
gs://mybucket/abc/file.txt
gs://mybucket/abc123/file.txt
```

this code results in an infinite loop:
```python
from fs import open_fs
open_fs("gs://mybucket/abc?strict=False").fix_storage()
```

In order to avoid this, we need to ensure `root_path` has a trailing
"/", when listing blobs, which prevents "abc123/file.txt" from being
listed as child of "abc".

Additionally, `Bucket.list_blobs` was deprecated in favor of
`Client.list_blobs` (see [reference documentation][1]).

[1]: https://cloud.google.com/python/docs/reference/storage/1.44.0/buckets#listblobsmaxresultsnone-pagetokennone-prefixnone-delimiternone-startoffsetnone-endoffsetnone-includetrailingdelimiternone-versionsnone-projectionnoacl-fieldsnone-clientnone-timeout60-retrygoogleapicoreretryretry-object
@manuteleco manuteleco force-pushed the fix_dir_blob_creation branch from 3789f49 to 1809e10 Compare July 17, 2023 20:36
@manu-crealytics

Copy link
Copy Markdown
Author

Not sure if that's at all relevant, but I don't see this banner anymore:

We are unable to start your build at this time. You exceeded the number of users allowed for your plan. Please review your plan details and follow the steps to resolution.

Did anything change on your side? Are PRs expected to trigger builds again?

I've applied a git push --force replacing the commit, but still nothing happened.

How should we proceed?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants