Thanks for the quick answer.

I will look into that carefully, but that looks (1) a lot of work and (2) like kissing goodbye to portability (I have already small platform specific snippets, but here we seem to be talking of a totally different level of platform specificity).

My naive question is: why Perl port on WinXP does not use natively the "good" routines, etc. and falls victim of these last-century limitations? Especially that you CAN avoid them in WinXP (and some applications do) and the file systems have no such ridiculous limitations.

Thanks!

p.

Support for Win9x has just been dropped from Perl, so you might actually see a move to the *W APIs in Perl. Of course, it will move faster if you contribute a patch :).

The major obstacle in moving towards the *W APIs is that much of the Perl code assumes that filenames are plain ASCII and have no encoding attached, which is obviously not the case with the *W APIs anymore.

You are not being very generous. Perl is written in C, and the C standard defines a constant FILENAME_MAX which is set to 260 in the Microsoft header files.

There is another Microsoft specific constant called MAX_PATH, and to quote the MSDN: "In the Windows API, the maximum length for a path is MAX_PATH, which is defined as 260 characters."

Exceptions are when using the Unicode interfaces and WCHARS, as you imply, which give a theoretical filename maximum of 32,767 characters. The sting in the tail of using such filenames is that there are several Microsoft APIs that do not support them; quoting the MSDN again: "It is possible to create a path with the Windows API that the shell user interface might not be able to interpret properly.". I don't think it is unreasonable that supporting such filenames has not been a priority.

Those 260 chars are a limit of Windows since the old ages. There are some tricks for breaking the barrier, by using the (most times) shorter aliases of longer names (I used that trick in deepcopy), but it does not help forever.

Why do you thing you need names that long? Do you put information into the filename that belong elsewhere? Use a meta-data file, or stuff the data into a database.

Alexander

Thanks, I am having a look to deepcopy, it may prove useful and efficient for me to play similar tricks.

As for why I need long pathnames, I guess it is not a germane issue here, but you are essentially right: I put in pathnames information which could (and perhaps should) be stored elsewhere. In a nutshell, (1) standard meta-data tags are all but standard content-wise and every second program thinks to be in the right to mess them up and be more clever than the previous tagger, and (2) a home-cooked database storage is invisible to all but my programs whereas directory structures are visible to all, in every OS, in every system, and I can control them quite freely. Not elegant, not the ideal solution, questionable under many aspects, but works quite fine for me--were it not for some limitations of some OSs. Luckily there are other OSs readily available around. But it is an exquisitely personal choice dictated by practical reasons--in principle you are probably perfectly right.

Thanks,

p.

You know what. I'd love to see you post an example of a path that reasonably (look it up) justifies the use of a path that requires more that 260 chars.

This brings to mind the Bugatto Veyron. That's a 8-litre, 16 cylinder, 1001 bhp, 256 mph/ 407 kph, $1e6, 2-seater sports car. Technically achievable, but of no practical value at all.

audio/flac/Classical/Bach, Carl Philip Emanuel (1714-1788)/Die Israeliten in der Wüste, Oratorio -- Schlick, Lootens, Meens, Varcoe, Corona et Cappella Coloniensis, Christie/19 -- Rezitativ und Arie Zweyte Israelitinn 'Beneidenswert, die ihren Sohn'.flac

Is this reasonable? Questionable, but it works for me and see the answer to afoken.

p.