RFE: Rules for permitting or rewriting file paths

[mtbcarroll]

MakePathComponentSafe includes various rules to make file paths even comfortably manipulated from shells on Windows machines. mlinkert suspects that, at the least, prohibiting spaces and periods on the end of filenames (at present, appending an underscore) is a problem.

Perhaps the server should be much less conservative in what filenames it accepts. For instance, regardless of the Windows shell, perhaps from Java the system can be more permissive. On a Unix system with a fairly Unixy filesystem then the server can be permissive indeed, at the cost of making later migration to Windows difficult.

The interaction with clients is another issue: it would be good if clients didn't have to have a bunch of special-casing depending on server configuration.

(All this becomes much easier under Java 7.)

So, what should be done? At least, if server restrictions are to be loosened, we need to reexamine the current restrictions: from where did they come, and to what extent could the server detect them as problems on the current system? And, arising from that, perhaps the sysadmin could configure how loosely they wish the server to behave.

[mtbcarroll]

mlinkert had mentioned that, especially, not being able to end filenames with spaces or periods is a problem; this conflicts awkwardly with the advice at ​http://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx viz.,

Do not end a file or directory name with a space or a period. Although the underlying file system may support such names, the Windows shell and user interface does not.

This suggests two levels of problem that are probably worth distinguishing in the code: what won't work at all on Windows, versus what will probably work from Java but might make things a bit tricky for the sysadmin.

[mtbcarroll]

​https://github.com/openmicroscopy/openmicroscopy/pull/1109 should largely fix this, except for the question of what's needed from the UI side. FilePathNamingException contains enough information for a client to explain to the user what the problem is; once this UI element exists in clients, perhaps the path sanitization occurring in the code around ImportLibrary.createImport should be wholly elided.

[jamoore]

Mark: happy to omit the sanitization in my importSets PR if you'd like. If so, feel free to close this ticket.

[mtbcarroll]

@jamoore: yes, thanks, sounds good to me, any questions I'll be glad to help.

[Josh Moore <josh@…>]

(In [301b4f70319aa9df8f916a5190ee058a2c7ad6d7/ome.git] on branch develop) Merge pull request #1109 from mtbc/trac-10671

fix #10671: make server handling of odd file paths more configurable