ignore files starting with . when loading folders

[mockersf]

Objective

• When loading a folder with dot files inside, Bevy crashes:

thread 'IO Task Pool (1)' panicked at crates/bevy_asset/src/io/mod.rs:260:10:
asset paths must have extensions
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

• those files are common for other tools to store their settings/metadata

Solution

• Ignore files starting with a dot when loading folders

[doonv]

I feel like we should add more customization for this. Maybe a custom regex filter or a whitelist/blacklist?

[alice-i-cecile]

Can we instead avoid panicking? It seems like the core problem here is that we're mis-parsing a folder as a file.

[FrTerstappen]

Would this be fixed by #10153 ? That seems to be a more general solution.

[mockersf]

I feel like we should add more customization for this. Maybe a custom regex filter or a whitelist/blacklist?

We could, but that's not the same. It's a standard behaviour to avoid dot files that are not yours, unless asked explicitly by the user. This is what this PR is doing.

Can we instead avoid panicking? It seems like the core problem here is that we're mis-parsing a folder as a file.

In this case the issue is that we try to get the extension of a dot file and that doesn't work. #10153 could be a way to fix this, but I think this PR is about not going though dot files that should not be read anyway.

[mockersf]

I strongly feel that dot files should be loadable by bevy and that this would be needlessly restrictive. I had actually planned on using them. Can we look into fixing the actual problem which seems to be detection of file vs directory. 10153 is part of what I was awaiting.

This doesn't block loading dot files, it just doesn't load them when not trying specifically to, which is what most tools do by default

[NthTensor]

I support this as a sane default (especially with how apple likes to litter dot files around the FS), but why make this change in AssetServer rather than in FileAssetReader? This seems more like a storage detail.

[mempler]

I would love a .bevyignore for those cases.

A simple gitignore-like file that has wildcards should be good enough.

[porkbrain]

Agreed on .bevyignore. I stumbled over two cases:

1. The artist I work with uses photoshop which generates some annoying files (debug.log) every now and then. They overwrite images in the asset folder to preview them in game.
2. We use godot editor for positioning and friendly UI. We have our Sprite2D, AnimatedSprite2D and other nodes describing some components. I parse the .tscn files into a representation that is loaded from assets and used to spawn relevant scenes. To keep things in sync, I root the godot project in such a way that it "sees" into the same assets directory as bevy. Godot generates *.import metadata file for each asset.

In the game I use asset server to load a whole folder. I have something akin to State::Loading that transitions into State::InGame when relevant folders are loaded. However, the asset server refuses to load my folders due to

Failed to load folder. Could not find an asset loader matching: Loader Name: None; Asset Type: None; Extension: None; Path: Some("a path to either debug.log or a *.import file");

If I could tell bevy which patterns to ignore that'd solve the two use cases above without having to change the loading logic which worked well for me so far.

[mockersf]

Setting up some kind of configuration or a bevy ignore file is a bigger change that I'm not convinced I want.

I updated the PR to filter in the file asset reader. This makes Bevy file listing standard with what most tools are doing.

[extrawurst]

I just ran into this today. Would be lovely to see Bevy not try to load (and fail unrecoverably) the weird macOS .DS_Store files when loading a folder

[NthTensor]

.DS_Store is exactly what I was thinking. I'll review again now that this is in the asset reader.

[NthTensor]

LGTM

[extrawurst]

@NthTensor @mockersf any chance this makes it into 0.16?

[NthTensor]

We could, but I'd rather not tbh. This behavior could be unexpected, and merging unexpected behavior on the third release candidate has been bad before. I'd prefer to make sure we get some user reactions to this before it goes out.

That's not a no, just my concerns.

[extrawurst]

I had to try :P

[thepackett]

Although this PR could be superseded by something more sophisticated like a .bevyignore, I think that this is important enough to implement now. Without this PR there is basically a subtle incompatibility with macOS that someone developing an application on windows or linux may not notice until well into development.