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

MAX_PATH issue on Windows ? #674

Closed
Remi-Gau opened this issue Nov 18, 2020 · 4 comments
Closed

MAX_PATH issue on Windows ? #674

Remi-Gau opened this issue Nov 18, 2020 · 4 comments

Comments

@Remi-Gau
Copy link
Collaborator

Could not find an issue where this was raised in the specs or for the validator and to my knowledge this is not mentioned in the specs so I am opening an issue.

In brief, because Windows imposes limitations on the fullpath length of filenames to 256 characters, would it make sense to cap the length of full path of filenames.

This sounds like an edge case but if people start using several of the entities in some filename and they get very verbose with their labels, this could still be an issue.

Also thinking about the fact that derivatives name might have the tendency to get longer.

@sappelhoff
Copy link
Member

I didn't look into it too deep, but perhaps this is related: https://github.com/bids-standard/bids-validator/issues/190

@effigies
Copy link
Collaborator

IMO this is outside the scope of the spec. I would suggest we move this discussion to the validator.

@Remi-Gau
Copy link
Collaborator Author

Good catch! Definitely a lead into a potential rabbit-hole. 🐰

OK so it is mentioned in the bids-2-devel: bids-standard/bids-2-devel#8

I think that contrary to what that issue mentions it could be more of an issue for Windows than for AFNI.

Not sure how many datasets in the wild could be affected by that problem.

Also I think it may be a nice thing to issue a warning for long file names.

@Remi-Gau
Copy link
Collaborator Author

IMO this is outside the scope of the spec. I would suggest we move this discussion to the validator.

OK I will close this here for now, though I suspect that maybe this validator rule should eventually make its way back into the specs.

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