Lines Matching full:filenames
231 <tr><td > <code>_DATA</code> </td><td > Probably should not be visible to applications. <b>WARNING</b> Security concern: This holds filenames, including those of private files. While file permissions are supposed to kick in and protect the files, hiding private filenames deeper in would probably be a reasonable idea. </td></tr>
260 If the <code>URI</code> column gets hidden, it could be used to store the intermediate URIs. After 1.0 the only available integer columns were <code>METHOD</code> and <code>CONTROL</code>. <code>CONTROL</code> was re-exposed to applications and can't be used. <code>METHOD</code> is slated to be re-used for 503 retry-after delays. It could be split into two halves, one for retry-after and one for the redirect count. It would make more sense to count the redirect loop with <code>FAILED_CONNECTIONS</code>, but since there's already quite some code using it it'd take a bit more effort. Ideally handling of redirects would be delayed until a future release, with a cleanup of the database schema (going along with the cleanup of the handling of filenames).
681 <li> I intend to refine the handling of filenames and content URIs, exposing separate columns for situations where a download can be accessed both as a file and through a content URI (e.g. stuff that is recognized by the media scanner). Unfortunately at this point this feature isn't clear in my mind. I'd recommend using reflection to look for the Downloads._DATA column, and if it isn't there to look for the FILENAME column (which has the advantage of also dealing with the difference between 1.0 and Cupcake).
932 <li> Deal with filenames with invalid characters.
934 <li> Refine the logic that builds filenames to better match desktop browsers - drop the query string.
936 <li> URI-decode filenames generated from URIs.
938 <li> Better deal with filenames that end in '.'.
942 <li> Investigate how to better deal with filenames that have multiple extensions.
