https://issues.apache.org/bugzilla/show_bug.cgi?id=42141
--- Comment #12 from Sebb <[email protected]> 2011-09-19 11:10:19 UTC --- (In reply to comment #11) ... > So the actual solution I propose for all platforms : > - allow anything to be typed in by the user as a filename, > - use the "second line trick" (getParentFile().mkdirs()) to avoid directory > separator problems, > - try to create the file using createNewFile() and redisplay the file save > dialog whenever an exception is thrown, while showing the error message to the > user so that she can correct the filename accordingly, > - _never ever_ change the user's input without at least telling her. That seems very sensible; let the JVM/OS do the work. I just wonder whether one should use mkdirs() before trying createNewFile()? [ignore my comment #4 about allowing separators, not relevant here] If I include a directory separator in a sampler name, do I really want to create the file in a subdirectory? I would have thought the normal usage is to create all the files in the current directory; if they start being saved in a different directory just because the name happens to contain a path separator, that could be very confusing. Also, what about leading ../ path segments? Should those be allowed? With the current JMeter (WinXP), these are accepted [and they change the default working directory for the File Save dialog!] And xyz/abc is also allowed if there is an existing xyz directory. I'm inclined to disallow parent segments as well (the user can still navigate to the required directory). This will require a specific check; we cannot use createNewFile without risking accidental changes to arbitrary directories. As an aside, it would be useful to have some JUnit test cases for the code, so it would be helpful to have the validation as a separate method. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
