Disallow file and folder names that end with dots #7772
Conversation
…, remove unused strings
JeffryBooher
changed the title
|
Be careful when testing this. Folders with trailing dots are impossible to get rid of. The operating system will brackets and windows explorer create them but not delete them. You will get "The specified path does not exist" so create them in a folder that you can later delete. I mistakenly created them in the |
JeffryBooher
changed the title
|
@JeffryBooher Just figured out why I was confused in the standup :-) Files and folders don't behave the same way:
So it seems like the fix should be the same in both cases, though: disallow creation in the first place, as this PR does. |
|
Btw @JeffryBooher, how do you get rid of a ".."-suffixed folder once you've created one? :-) |
|
@peterflynn yeah this was a PITA for me. So Make sure it's in a folder that you can delete and then you have to remove the parent folder and ignore errors. I think it's |
| StringUtils.format(Strings.INVALID_FILENAME_TITLE, isFolder ? Strings.DIRECTORY : Strings.FILE), | ||
| StringUtils.format(Strings.INVALID_FILENAME_MESSAGE, _invalidChars) | ||
| StringUtils.format(Strings.INVALID_FILENAME_TITLE, isFolder ? Strings.DIRECTORY_NAME : Strings.FILENAME), | ||
| StringUtils.format(Strings.INVALID_FILENAME_MESSAGE, isFolder ? Strings.DIRECTORY_NAMES_LEDE : Strings.FILENAMES_LEDE, _invalidChars) |
There was a problem hiding this comment.
It seems like a bunch of these string diffs are just here to change the dialog message from "file name" to "filename." I think "file name" is actually better -- and it seems like it would simplify the diff too.
CC @njx for the string question
There was a problem hiding this comment.
I'm very used to "filename" (and that's how we tend to treat it in code - we don't inner-cap the N). For user-facing strings "file name" is probably more standard English, though for technical users it might be different - I have a suspicion that coders are probably more used to "filename", though I don't have any data.
(FWIW, I did a search in Adobe's help docs, and it seems like the documentation itself usually uses "filename", but when it refers to label strings in the UI they tend to be "File Name", probably because they need to be capitalized and "Filename" looks weird. That doesn't apply to this case anyway since it's uncapitalized in a message string, not being used as a label.)
Anyway, I guess after all that I don't have a strong opinion either way :), as long as we're consistent. I didn't see any other user-visible uses of "filename" in the current strings file, so I think this one could go either way, and we can follow it elsewhere. Personally, I think it's fine to keep it as "filename".
There was a problem hiding this comment.
@njx Actually it looks like all of these should be uppercase, since they're being used in a dialog title. I think it's a bug in the PR (and on master!) that they're lowercase.
There was a problem hiding this comment.
@peterflynn Well, I changed this because you're right we should be Title Case on the titles but having trouble testing it. I tried removing all permissions on a folder except for "Read" and renaming a file I ran into "Error renaming file" then I noticed we also have "Error deleting file", "Error loading project". I'm not sure how deep this issue goes and it could go kind of deep.
We could try to fix all of them, just this occurrence or raise an issue to fix them all at once. We could attempt to fix them using a css text-transform (text-transform:capitalize) but I have no idea how that works with localization. It may not work or not work it incorrectly in some scenarios.
|
@redmunds go ahead and give this a final review and merge if it's ready. I'll move the discussion of UI to another issue so we can capture the larger 1.0 UI Audit |
|
LGTM. Merging. |
Disallow file and folder names that end with dots
Fixes:
#5468 (although I was never able to entire reproduce this case)
#7224
This will allow for the user to create dots at the end of a file or directory name using the OS (finder/explorer) and Brackets will honor those but, because of the complexities of how the OS treats trailing dots in entity names, we disallow the user from creating entities that end with dots.
This is not for Sprint 39