Hey there, we've just had an OS X user report that they are unable to clone our Git repo fully because the file names for a query and a component clash with each other (changeusername.yml and ChangeUserName.yml ). Git users on Windows would face the same issue. There's already functionality in the UI that stops the same name being used twice, would it be possible to extend that so that it can also stop these case-sensitive name clashes?
3 Likes
Since your current UI already prevents duplicate file names, you could enhance this validation by comparing file names in a case-insensitive manner. This would ensure that files like changeusername.yml and ChangeUserName.yml aren't allowed to coexist, which could cause issues for users on certain operating systems.
You can do this by converting all file names to lowercase (or uppercase) before the comparison:
let existingFiles = ['changeusername.yml', 'someComponent.js'];
let newFile = 'ChangeUserName.yml';
// Convert both the existing file names and the new file name to lowercase
let caseInsensitiveMatch = existingFiles.some(file => file.toLowerCase() === newFile.toLowerCase());
if (caseInsensitiveMatch) {
throw new Error('File name conflicts with an existing file (case-insensitive). Please choose another name.');
}
This will prevent a file from being created or uploaded if its name matches an existing one, regardless of case.
Alternatively, you could implement a server-side or version control check if the case-sensitive clash happens after files are pushed to Git. A simple Git pre-commit hook can also help detect and prevent these conflicts before pushing.
Hopefully this can put you on the right track.
1 Like
The content and timing of this response looks a lot like an LLM bot and not a human.
To be clear, I'm talking about the retool UI, not my app. We already have a GitHub Action set up to detect this situation but the developer then needs to go and rename things after the fact, it would be a nice improvement to stop it happening in the first place!
Yeah I’m definitely an LLM. Haha Anyways jokes aside my bad because I wasn’t super sure if it was retool specific honestly so I was guessing based on your initial post because retool doesn’t have strict guidelines on this at all. What your developer does when they go in to rename things is probably the best way to work through it without writing a script to change all of it for you automatically (not the best solution). I would recommend finding a solid naming convention system so this doesn’t happen in the future until retool changes this.
2 Likes
Thank you, @TRF, for suggesting the potential workaround of adjusting file names to avoid case-sensitive conflicts. It's always great to see community members offering thoughtful solutions!
Thank you for raising this request, @edbordin-linktree. I've submitted a feature request on your behalf to address this issue more directly. I'll comment here with any updates as they come.
1 Like
@edbordin-linktree can you verify your version number? 3.75.6?
1 Like
@AbbeyHernandez Correct, we're running 3.75.6!
2 Likes
Are you on ToolScript? @edbordin-linktree
1 Like
No, the requirement to migrate everything at once has meant we've stayed using the legacy YAML files for now - we have a lot of apps and were hesitant to make such a huge change in case it broke multiple things at once. Perhaps that was overly cautious though!
Thank you! I'll ask our engineering team their opinion and get back to you about if ToolScript is a good choice for your org 
It's something to consider! Eventually your org will need to migrate to ToolScript, because we are deprecating YAML. At this time several customers have migrated and it seems stable. More can be read about it on this forum announcement.
I just learned that because of it's deprecation, we will no longer be shipping bug fixes for YAML. However this is not a known issue in ToolScript. I looped in Matt McDonald on these updates! If you have any follow up questions, I'm happy to help
2 Likes