[zanata-bugs] [Bug 993450] Unhandled exception: Long file and path names can cause a path validation exception

[bugzilla at redhat.com]

https://bugzilla.redhat.com/show_bug.cgi?id=993450



--- Comment #1 from David Mason <damason at redhat.com> ---
The error message at the moment does not provide enough information for users
to know what has gone wrong. It is just "Failed to upload this file."

There are several stages we can use to improve user experience around this:

1. Ensure that the error message when this happens indicates that the
path+filename length is too great. At this stage the error would still only
show after the user has attempted to initiate upload.

2. Add a check in the dialog that will display an error message and disable the
upload button whenever the length of path + any filename in the list is greater
than 255.

3. Increase the limit on path+filename length. Considerations for determining a
sensible limit:

 - what URL length can be handled by typical user agents (browsers etc.)?
 - what path+filename length can supported operating systems handle?


Some research about path and filename lengths on operating systems indicates
that a limit of 255 characters is sensible for the filename on its own, but the
limit on total path+filename length could be set as high as 4096 without
causing problems on typical Linux systems, and as high as 32k for Windows
systems (as long as individual path components should are limited to 255
characters).
There is a lot of complexity in this area, so there is no simple solution that
will work everywhere. Owncloud use an interesting solution, where clients check
that paths are valid for the file system, and for paths that cannot be used
they alias the original path to a locally valid path. 

   see: Cross Platform File Handling | owncloud/core :
https://github.com/owncloud/core/wiki/Cross-Platform-File-Handling


For browsers, a sensible URL length limit is 2000 characters. Since path is
used in some of our REST URLs, a limit of 1450 characters or so might be
sensible to allow for project and version slug length and other URL components.
The other option would be to use something more constrained than path+filename
as the REST URL for a document. This would require adjustment to how all the
clients use the REST interface, and would probably increase the required number
of REST calls since some metadata would be needed to find the id of a document
based on its path and filename.

    see: Top answer: What is the maximum length of a URL in different browsers?
http://stackoverflow.com/a/417184/297938

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=8e9xN51Qut&a=cc_unsubscribe