[PD] Large File Support on Linux

[IOhannes m zmölnig]

On 03/20/2013 18:02, Miller Puckette wrote:
> On further thought, I don't think it's even possible to change open_via_path()
> to use open64() and maintain even source compatibility for externs - if
> one of them calls lseek or fstat we're sunk - and I don't see any robust
> way of aliasing those calls to lseek64() etc.

yep.
that's why i said that the only real solution would be to provide a
more-or-less complete set of fileIO-functions: sys_lseek, sys_stat
(including f-variants).

> 
> I'm now realizing too that I don't know what approaches the Mac and Microsoft
> pltforms are taking to large file support - I think any solution will have to
> somehow address all of the platforms.

which would be possible if we provided the full set. of file accessors.
(but to repeat, this is not really a Pd-problem, and could (and maybe
should) be solved in an auxiliary lib).

> For right now I'd like a way to fix 0.44's sfread~ - I'm thinking I can do
> that internally to d_soundfile.c so as to cause the least possible disruption
> in a 'bugfix' pd release (probably 0.44-3).

which i think is a good enough approach.
but of course there's a catch: sys_open() will gracefully handle UTF-8
filenames, whereas on some platforms open() will not.
so with your solution, soundfiles with non-ascii chars will fail to open
on W32.

since open_via_path() is so often used to determine the full path of a
file somewhere in the searchpath, it might be a good idea to wrap that
functionality into a find_via_path() function that returns the
canonicalized filename. it would be great if that filename would be
mangled in a way so UTF8 doesn't make problems any more, but i think
this is simply not possible with the way w32 handles opening such filenames.


fgmadsr
IOhannes