-
Notifications
You must be signed in to change notification settings - Fork 7.6k
Disallow file and folder names that end with dots #7772
Changes from 2 commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -185,7 +185,8 @@ define(function (require, exports, module) { | |
* RegEx to validate if a filename is not allowed even if the system allows it. | ||
* This is done to prevent cross-platform issues. | ||
*/ | ||
var _illegalFilenamesRegEx = /^(\.+|com[1-9]|lpt[1-9]|nul|con|prn|aux)$/i; | ||
|
||
var _illegalFilenamesRegEx = /^(\.+|com[1-9]|lpt[1-9]|nul|con|prn|aux|)$|\.+$/i; | ||
|
||
var suppressToggleOpen = false; | ||
|
||
|
@@ -1529,8 +1530,8 @@ define(function (require, exports, module) { | |
filename.match(_illegalFilenamesRegEx)) { | ||
Dialogs.showModalDialog( | ||
DefaultDialogs.DIALOG_ID_ERROR, | ||
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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It's kind of hard to read the list of invalid chars on my Windows HiDPI laptop monitor because they're kind of small and jammed together. What do you think about having a separate There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @redmunds putting a space in means that we maintain 2 strings whenever we update it. Bold works b/c we can just write the format around it. Let's do that and see how it looks on your machine. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. You can use There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. ... or we could use a fixed width font and bold it. try it now @redmunds There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That looks good to me. |
||
return false; | ||
} | ||
|
@@ -1657,15 +1658,13 @@ define(function (require, exports, module) { | |
}; | ||
|
||
var errorCallback = function (error, entry) { | ||
var entryType = isFolder ? Strings.DIRECTORY : Strings.FILE, | ||
oppositeEntryType = isFolder ? Strings.FILE : Strings.DIRECTORY; | ||
var titleType = isFolder ? Strings.DIRECTORY_NAME : Strings.FILENAME, | ||
entryType = isFolder ? Strings.DIRECTORY : Strings.FILE; | ||
if (error === FileSystemError.ALREADY_EXISTS) { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is a nice simplification! (Using a more generic string and eliminating the "opposite type" stuff here). |
||
var useOppositeType = (isFolder === entry.isFile); | ||
Dialogs.showModalDialog( | ||
DefaultDialogs.DIALOG_ID_ERROR, | ||
StringUtils.format(Strings.INVALID_FILENAME_TITLE, entryType), | ||
StringUtils.format(Strings.FILE_ALREADY_EXISTS, | ||
useOppositeType ? oppositeEntryType : entryType, | ||
StringUtils.format(Strings.INVALID_FILENAME_TITLE, titleType), | ||
StringUtils.format(Strings.ENTRY_WITH_SAME_NAME_EXISTS, | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. JSLint error:
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm using The |
||
StringUtils.breakableUrl(data.rslt.name)) | ||
); | ||
} else { | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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.