|
2014-03-11
| ||
| 13:06 | • Closed ticket [c060923a]: VFS filename truncation issues plus 3 other changes (artifact: fc3c4605 user: drh) | |
|
2009-10-19
| ||
| 05:17 | • Ticket [c060923a]: 3 changes (artifact: c2f7e29d user: rogerb) | |
|
2009-10-10
| ||
| 03:18 | • New ticket [c060923a]. (artifact: 2b6ea725 user: rogerb) | |
| Ticket Hash: | c060923a5422590b3734eb92eae0c94934895b68 | |||
| Title: | VFS filename truncation issues | |||
| Status: | Closed | Type: | Code_Defect | |
| Severity: | Severe | Priority: | Immediate | |
| Subsystem: | VFS | Resolution: | Wont_Fix | |
| Last Modified: | 2014-03-11 13:06:54 | |||
| Version Found In: | 3.6.2 | |||
| Description: | ||||
|
http://www.sqlite.org/cvstrac/tktview?tn=3373
In essence the Unix VFS uses a hard-coded limit of 512 bytes for a fully qualified filename, truncates anything longer than that, and then gives can't open error on having stuffed the situation up. In practise current Unix systems have maxiumum pathname lengths of 4096 bytes which means there are files that SQLite can't open. Note the truncation happens even if a fully qualified pathname is passed in. This has also affected mozilla. The Windows VFS has the same problem but it's default max length is the same as Window's. However Windows does allow pathnames to be prefixed by "\\?\" which then uses an alternate path parser with a 32kb limit. rogerb added on 2009-10-19 05:17:39: | ||||