This content has been marked as final. Show 25 replies
The only thing that I couldn't escape with without wasting any time was "/":
hakan@hakan-laptop:13:57:14:~/test$ touch \<\:\|\?\*\(\)\%\&\'\$\@\^\~\#\"\>
hakan@hakan-laptop:13:58:20:~/test$ ls -l
-rw-rw-r-- 1 hakan hakan 0 Oct 23 13:57 <:|?*()%&'$@^~#">
Why not actually spend some time on how to sanitize a name so that it does not look like a filename instead of making up random rules?
Many products take the approach of sanitizing invalid filenames (e.g., a print-to-pdf driver like PrimoPDF -- the user has an opportunity to confirm the change). I believe SQL Developer only takes that approach in some export areas where there is no user interaction and the process must be fully automated.
As for your example, results vary by operating system. On Windows 7, either natively or using touch from an ancient version of the MKS Toolkit...
The filename, directory name, or volume label syntax is incorrect.
So does the benefit of correctly supporting all possible environments warrant the cost? We think not.
Jeff Smith SQLDev PM wrote:Unfortunately, this doesn't appear to be entirely accurate. Using 3.2.20.09 under Windows 7. The parenthesis - '(' and ')' - in particular, appear to have been missed. They are a valid file system character on both Windows and Linux, but Oracle SQL Developer is no longer supporting them - and echoing previous comments, despite having many existing connection names using these characters.
Version 3.2.2 was released late yesterday. It includes this change. If your file system supports the character in file and directory names, you can use it in the Connection Name.
I agree with previous comments that any file-system reserved characters should have been properly escaped instead. This doesn't necessarily mean forcing the OS to store the special characters literally (as was demonstrated by Hakan) - but using something like percent encoding (http://en.wikipedia.org/wiki/Percent_encoding) to serialize the name to disk, while still allowing for unrestricted characters in the actual connection names. (The same approach that is used to properly convey filenames and other data within URLs, for example.)
The other problem with the current state is that now a standard is being supported that isn't platform-independent. If we want to share connection profiles across teams, etc., we have to think - will all of these names work under Windows? Will they work under Linux? Better to avoid the issue all together, and just escape / encode any characters beyond the basic set.
Edited by: ziesemer on Nov 4, 2012 2:15 AM
(Guess the stated hyperlink syntax is broken here...)
Again, I guess I'm confused as to what is even driving these restrictions, other than "Many bugs reported around connection names involving quoted strings, etc necessitated the new naming rules." Again, it seems like the better approach would have just been to fix these bugs, rather than add these additional user restrictions. In particular, I see the elimination of the colon, slash, parenthesis, and at sign being very significant - all of which were in use within not only my SQL Developer instance, but most of my group. Even the JDBC connection strings make use of the colons and at sign, for example - and several of our connection names followed this standard to reduce ambiguity and keep a sense of standards.
This is an important enough issue to me and one that I feel strongly enough about that I'd like to contribute a patch, etc. to properly solve this without the additional restrictions (using the proper character escaping / encoding that I mentioned previously). However, I don't believe that SQL Developer is open-source, nor the source code even available for review. If I put together a stand-alone utility class that would do the conversions between the "connection name" (display name) and file-system names, accounted for all known cross-platform issues, and was supplied with JUnit test cases - is this something that would even be considered for inclusion into the product, even if just by following the same approach if not inclusion of the actual code? (I just wouldn't want to complete this effort if the resulting work wouldn't even be considered.)
Just yesterday I read a [rant on PHP|http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/]. Today I get stumbled on this. Same story if you ask me!
Jeez, guys, you make the RDBMS! Can't you look up how to escape strings for XML and FS??? What kind of "costs to warrant" are you talking about???
Every time I view the Data in a table I get a "Connection is currrently busy. Try again?" alert with the results coming behind the alert! The right thing to do - click Abort! Every time! This bug hasn't been fixed for months now! Notice the 'rrr' in 'currrently', it's been there for a few versions, too.
Do you by any chance use the tools you make?
Sorry about the tone. I'm really tired fighting the tools full of quirks just to use a DBMS full of quirks...
Please take it as a +1 on properly escaping the names.
P.S. How do you insert a link here? Links [produced by your WYSIWYG editor|http://www.oracle.com] do not seem to work.
I'm not sure what Jacob considers to be "resolved". Using 3.2.20.09.87, the problem with not being able to use the characters mentioned here previously certainly still exists. +1 for user7393108's post on 2012-11-15.
To extend upon my previous post, these files should be stored using something like Percent encoding (a.k.a. URL encoding). Given the following connection names (based on JDBC connection strings):
The resulting folder / file names could (should) be (respectively):
This approach has the benefit that any plain text (e.g. "username", "server", "1521", "service", and "SID" in these examples) is still plainly visible in the encoded form.
Even something "crazy" like a username that contains a percent-sign can still be encoded. For example:
This is the benefit of an encoding method that actually works (doesn't have any "unsupported" characters).
Now, this requires allowing the percent-sign to be stored in the filename. I can't imagine why it wasn't allowed in the first place, as it is easily supported under both Linux and Windows. (If the '%' can't be supported in the filename for some crazy reason, it could be substituted with some other character - but then the algorithm would have to be updated to match, and would become non-standard.)
Can someone from the SQL Developer development team please shed some light on why this has to be so difficult?
I opened the thread with the concern of spaces, dots, and dashes not being allowed in connection names. That is resolved, and I marked my question answered.
This thread has ballooned into related, but other concerns from my original post. I was marking my question answered and closing my thread. I have no knowledge of how these threads make it into Oracle employee's workflows - so you may want to open a new, separate thread with your inquiry in the hopes that it is read as an "open" question.
Happy Thanksgiving, USA folks.
Jacob - thanks for the clarification.
I did try opening a ticket for this at http://sqldeveloper.oracle.com/ - but am unable to complete the submission due to the following error:
ORA-01461: can bind a LONG value only for insert into a LONG column Unable to process row of table FEATURES.
I also did open Oracle SR # 3-6467771651 to address these concerns.