]> git.vanrenterghem.biz Git - git.ikiwiki.info.git/blob - doc/bugs/aggregate_generates_long_filenames.mdwn
confirmed
[git.ikiwiki.info.git] / doc / bugs / aggregate_generates_long_filenames.mdwn
1 the [[plugins/aggregate]] plugin mashes the `title` of an aggregated post into a filename.  This results in long filenames.  I have hit a filesystem length limitation on several occasions.  Some (ab)uses of RSS, e.g., twitter,
2 generate long titles.  Especially once you throw escaping into the mix:
4     $ ikiwiki --setup testsetup --aggregate --refresh
5     failed to write ./test/lifestream/Hidden_Features_Of_Perl__44___PHP__44___Javascript__44___C__44___C++__44___C__35____44___Java__44___Ruby___46____46____46__._aggregated.ikiwiki-new: File name too long
6     aggregation failed with code 9216
7     $ echo $?
8     25
10 It would also appear this abrubtly terminates aggregate processing (if not ikiwiki itself).  Only after moving my test repo to `/tmp` to shorten the filename did I see newer RSS feeds (from a totally different source) picked up.
13 -- [[Jon]]
15 > I have to wonder what filesystem you have there where 147 characters
16 > is a long filename. Ikiwiki already uses `POSIX::pathconf` on the srcdir
17 > to look up `_PC_NAME_MAX`
18 > to see if the filename is too long, and shortens it, so it seems
19 > that, in additional to having a rather antique long filename limit, your
20 > system also doesn't properly expose it via pathconf. Not sure what
21 > ikiwiki can do here. --[[Joey]]
23 >> This is an ext4 filesystem with default settings (which appears to mean
24 >> 256 bytes for pathnames).  Despite the error saying file name, it's
25 >> definitely a path issue since moving my test repo to `/tmp`from
26 >> `/home/jon/wd/mine/www` hides the problem. I note the following comment
27 >> in `aggregate.pm`:
29                 # Make sure that the file name isn't too long. 
30                 # NB: This doesn't check for path length limits.
32 >> I don't fully grok the aggregate source yet, but I wouldn't rule out
33 >> a bug in the path length checking, personally.  I'm happy to try and
34 >> find it myself though :) -- [[Jon]]
36 >>> Path length seems unlikely, since the max is 4096 there.
37 >>> --[[Joey]]