Invalid files in dot directories may not produce errors

[effigies]

An OpenNeuro dataset contains sub-<label>/.ipynb_checkpoints/sub-<label>/sub-<label>_sessions-checkpoint.tsv. There is no .bidsignore but the validator is not raising an error

[yarikoptic]

my wrong initial take since I have not spotted that it is in sub-*/ folders

so the question is rather should we aim for whitelisting (might become tedious) vs blacklisting (impossible ;) ) dot-folders. It was actually the former until 6ff2669 if I searched it up correctly, and I would vote for the whitelisting. For some of them we might even recommend alternative placement(s), now that we have logs/ (e.g. instead of default .duct/ for our https://github.com/con/duct).

• could we disallow all dot-directories under non-top folder? With DataLad hat -- nope since could still be .git-submodules and .datalad-subdatasets
  • so we would need to revert back to while-listing, and then unclear if it should be only for sub-*/ folders or everywhere?!

[effigies]

What about .git*, .datalad/ and /.* to allow for submodules/subdatasets and root-level dot files?

[yarikoptic]

could/should we be more specific for .datalad/config ? otherwise some heavy .datalad/metadata etc might sneak in?

NB in dandiset DataLad versions we have .dandi/ with potentially heavy files. https://github.com/dandisets/000003/tree/99f2bb68aaea1207f06927ffb3cbe1b3647d9526/.dandi ... but not sure if those ever should be uploaded to dandi since would be a "checken/egg" issue (they are dumps of records from which that commit is populated), so we might explicitly skip them from validation etc if someone uploads from such a datalad version of it.

[effigies]

could/should we be more specific for .datalad/config ?

In subdatasets, yes. If we allow /.*, that will match /.datalad/should-not-be-here.

[effigies]

The current text reads:

Files and directories starting with a dot (.) are reserved for system use and no valid recognized BIDS file or directory can start with a .. Any file or directory starting with a . present in a BIDS dataset is considered hidden and not subject to BIDS validation.

I suppose the validator implements this exactly as written, so maybe this should just be closed.