Long path names

Paul,

we have the following problem: we want to compile a large code consisting of 350 subroutines in a specific directory. For this task we work with the following batch file:

del comp.lis
del *.obj
del *.exe
                                                                      
ftn95 DataTypes.f95             /checkmate /Full_Debug  >> comp.lis 
ftn95 CommonData_Broyden.f95    /checkmate /Full_Debug  >> comp.lis 
ftn95 Global_data.f95           /checkmate /Full_Debug  >> comp.lis 
ftn95 Utilities.f95             /checkmate /Full_Debug  >> comp.lis

ftn95 *.f95                     /Checkmate /full_debug  >> comp.lis

This standard procedure has worked for decades. However, when we put the files in a directory with the path

D:\\TU_Release\\v1m1j10\\No Numerical Recipes\\Transuranus\\TU_Input_Examples\\Test\\Compilation

we get after the compilation of few subroutines the error message

*** /NT_MULTIPLE_COMPILATàðÍ is not a valid option on the command line - use 
    FTN95 /? for valid options

However, when we shorten the name of the path somewhat, say to

D:\\TU_Release\\v1m1j10\\No Numerical Recipes\\Transuranus\\TU_Input_Examples\\Test\\Comp

the compilation works without problems.

Of course we have tried to analyze the problem. Blanks in names of subdirectories are allowed (except at the end of the name), underscores as well. The maximal allowed path length of 256 is by far not exceeded. We cannot see that the name of the path is incorrect. We have also checked that no old versions of salflibc.* etc. are in this directory. We have further checked whether in the manual some restrictions for the path name are given, but we could not find any. In addition, we have checked this behaviour on different PCs (all using XP Professional, SP3).

My question is therefore whether we have overlooked something or whether there are restrictions for the path names included in FTN95.

This is not an urgent problem but certainly a problem of interest.

Best regards,

11. Lassmann [/code]

There was a restriction on the length of the path when using FTN95 *.f95 etc. I think it was at about 130 characters. I fixed this on 10 January 2011 so the fix will not be in the current release. Why 130? It was old code written for a 16bit OS. The new limit will be 256 i.e. the standard for a 32bit OS.

Paul,

thank you very much for the very quick reply, which completely clarifies the problem.

Have a nice day,

Klaus

Paul,

In your fix, is this extension to 256 characters done for every case where a path is used, or is it only for a specific function or functions? (i.e. the context here is the path for a compilation, but there are instances in Clearwin, and also in some Silverfrost routines - such as GET_PROGRAM_NAME@ - that would appear to be limited to 129 or 130 characters and probably ought to be set to the bigger limit).

Eddie

There isn't an easy answer to this. The relevant limits are scattered around in a vast amount of code. We have fixed the code in this respect in a number of places over the last year or so but I cannot guarantee that every lower limit has be removed. If you suspect a problem remains then please let me know.

p.s. I will take a look at GET_PROGRAM_NAME@ anyway.

There does not appear to be any limit when using GET_PROGRAM_NAME@ other than the size of the character variable that you supply as an argument.

Thank you. I was (I suppose) cheekily asking if the limits were scattered around the code, needing to be picked off one-by-one, or whether there was a master number somewhere. I suspected the latter, as I only have the sketchiest idea of the inner workings of FTN95 ...

E