> Please note I don't maintain libc. Right.
> > /usr/include/fts.h, which is part of glibc, does not work with > > transparent Large File Support... > > The problem there seems to be struct stat *fts_statp in FTSENT. > There is one variant of struct stat for 32-bit file offsets and > another for 64-bit. fts_read and fts_children would have to know > which variant the caller expects, but they don't get that > information. Bletch. OK, this problem isn't likely to be fixed, then. > The fts functions are not documented in the glibc 2.8 manual. I think they're part of 'gnulib' rather than 'glibc'. I'm a bit fuzzy on the distinction. > If a program needs large-file support for recursive directory > operations now, it can perhaps be ported from <fts.h> to <ftw.h>, > which already supports large files but doesn't provide as many > features. In particular, it doesn't seem to detect hard links. Probably a problem for pax. I think the pax bug is likely to stay open. Thanks for your porting suggestions; I've solved my immediate problems by using cpio, which unlike pax or tar did not choke on my files. Norman -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
