Hi Przemek, >> The macro responsible to set maximum filename/path >> length in Harbour (HB_PATH_MAX) is now set to 264. >> Modern systems can handle much more as maximum path >> length (f.e. Windows 32K chars). > > AFAIR the longer paths are not for FS but for host name > in UNC notation though some FS can use much bigger values > then OS.
Yes. >> Shouldn't we extend this Harbour constant to handle >> more? >> There are few issues to take care of: >> - This macro is used for both filename and pathname >> max length in Harbour, maybe we should have two values >> to fix that. > > It will introduce unnecessary problems in path modifications > and it's not clear what does it mean and how to adopt it to > different FS limitations. > Current meaning is correct. This is the maximum size of complete > path. It doesn't matter it's single file in root directory or > series of directories. Important is only total size. F.e. on windows there is separate a limit for filename path component. I didn't make tests yet, anyhow worst case Windows API would generate errors when passed too long name, so I guess it alright for Harbour. >> - Set this constant to different values depending on >> platform. > > Potentially it's new problem for code which have to exchange > data between different Harbour builds. > >> - Many times the buffer is allocated on stack, we >> may need to revise whether using larger buffers here >> has any bad side-effect. > > If you plan to enlarge this value to 32KB then it will be > necessary to remove all such places and define that it's > illegal to use it directly or indirectly by some other > structures like HB_FNAME in C stack variables. For core > code it can be done (though with the cost of speed in some > cases) but it's potentially serious problem for 3-rd party > code. We will probably have to change current code and > hide HB_FNAME internals so user can use it on HVM stack. Okay. Binary compatibility is only a concern for minor revisions, so in this case it's no showstopper for us. pcode set was already updated, so even .prg code is not compatible in 2.1. It seems a viable path to first update current structures and core/contrib coding practices to allow for larger buffers without upping the limit itself, and after everything is in place, expand HB_PATH_MAX to allow for more. Since we need to present a limit anyway, at may also be a possibility, and an easier one to simple up the limit from 262 to 4096 on win/wce/*nix systems. This looks still okay to do on stack and would resolve the problem for (I believe) 99.999% of users (F.e. Cygwin project did exactly that in 1.7 release). Of course updating the internals to allow for more, is a nice thing in both cases, but only a requirement if we follow the first method. What is your opinion on above options? > Changing the value of HB_PATH_MAX breaks binary compatibility > with existing code so I do not think it's good idea to touch > without some serious reasons, i.e. real problems in some FS. I tested simple code on Ubuntu, and f.e. CURDIR() will simply fail when run in deeper than HB_MAX_PATH directory structure. It will return empty string. On Windows many upper level of OS/apps is quite faulty in this regard, so they behave strangely, even supplied Explorer is confused, so could not even execute apps from deeper path. I could run simple HB_FILEEXISTS() check and it fails as expected for anything longer than 262. Linux test code: --- PROC MAIN() LOCAL a := CURDIR() ALERT( HB_NTOS( LEN( a ) ) + " " + a ) // -> '0 ' shown when run from deep structure RETURN --- Windows test code: --- PROC MAIN() HB_ALERT( HB_FILEEXISTS( "C:\12345678901234567890\12345678901234567890\12345678901234567890\12345678901234567890\12345678901234567890\12345678901234567890\12345678901234567890\12345678901234567890\12345678901234567890\12345678901234567890\12345678901234567890\12345678901234567890\12345678901234567890\g.exe" ) ) // -> '.F.' shown, while the file exists HB_ALERT( HB_FILEEXISTS( "C:\12345678901234567890\12345678901234567890\12345678901234567890\12345678901234567890\12345678901234567890\12345678901234567890\12345678901234567890\12345678901234567890\12345678901234567890\12345678901234567890\12345678901234567890\g.prg" ) ) // -> '.T.' --- Brgds, Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
