Put_DIB_Block

My code includes a call to Put_DIB_Block@.

When I run the code from a subdirectory

D:\Kenya drone data 45.1 Gb ref\Samuel 15_16 segment images plots \Samuel_15_16_2023_12_13_MS_CSV JPG 1.14 Gb 41 TC v2 window 40

passing the file name

drone_img_hdr_Kenya_2023_24_SR_G_RE_NIR_SL_IS _ 1_window_40_centred_on_line_1221_pixel_1293 2023-12-13_Tigania_Samuel 37.78304_ 0.08933.jpg

the program drops outs somewhere inside the call to Put_DIB_Block@ (good old-fashioned print statements show that the program enters the routine, but doesn't exit). Interestingly, when I run the program under SDBG, it terminates somewhere within Put_DIB_Block@, without any error message.

However, when I paste the folder to nearer the top of the main directory

D:\Kenya code \Samuel_15_16_2023_12_13_MS_CSV JPG 1.14 Gb 41 TC v2 window 40

the program runs fine.

Any suggestions as to what is happening, and what I need to change so that my code runs in the deeper subdirectory.

Norm Campbell

Norm

As a standard practice path names are restricted to 260 characters but I can't see anything in the source code for Put_DIB_Block@ that would cause a problem.

If you can send me a short program that illustrates the failure then I should be able to locate the problem.

When I take the entire path name (drive,folder,file) I get 267 characters.

PUT_DIB_BLOCK determines the type of file to produce by using the file extent (in your case .jpg) as the target file format. But that is beyond the 260 character limit for a full path name.

Just as an FYI, within windows you can have a resulting path that, if taken as one name, can easily exceed 260 characters. But you cannot use a single character string longer than 260 characters to access the file. I have run into this problem with someone's software that created level after level of folders (with long names) then wondered why the code didn't work to get to the actual file.

That said, some routines (and PUT_DIB_BLOCK may be one) may perform a getfullpathname() API function call to get the full name including the directory/folder path. And there is likely a 260 character limit (MAX_PATH) imposed.

BTW: Apparently there is a way to access bigger/longer file names (see link below). That said, in my software (and in most others) this registry trick to allow bigger pathnames will not work with already compiled and running code.

https://www.autodesk.com/support/technical/article/caas/sfdcarticles/sfdcarticles/The-Windows-10-default-path-length-limitation-MAX-PATH-is-256-characters.html#:~:text=By%20default%2C%20Windows%20uses%20a,Files%2C%20Paths%2C%20and%20Namespaces.

Bill,

I am not sure how extensive this limit of 256 or 260 characters applies.

I googled limits and found: Maximum path length is 260 bytes for FAT with LFN support The maximum filename length on a NTFS partition is 256 characters, How to enable paths longer than 260 characters in Windows 10?

However, I don't know if this is a path limit in NTFS ? (You can't always trust google!)

I have uses FILES8@ for a long time to scan directories or disks and for the argument character (LEN=) FILES(NMAX), I have this defined as: CHARACTER FILES320(32000)

I don't recall a problem with 320, but integer2 NMAX ⇐ 32767 can been an issue with some system directories when using FILES@.

I am not sure what are the true NTFS limits for this, but if running on a FAT partition, this could be a cause of the problem.

John,

The limit, in characters of a file name, an individual folder name, or the fully qualified path name for NTFS is 260 characters (MAX_PATH).

I used to define my path names as 1024 characters. I was sadly mistaken. The limit is 260. No sense in making it longer, although that is certainly accommodated. For example, the CURDIR@() function can be defined to be 32 characters or 32000 characters. However, only the first 260 characters of the current working directory will be returned.

As I mentioned before, I ran into a program that created a set of folders each with a 32 character name, it created DOZENS of these, making the fully qualified path name to that file more than 260 characters.

The program had no problem reaching that far down because it would do the equivalent of an ATTACH@() to each folder in turn, traversing the folder path, until it reached the file name, then access it. But, my backup software didn't operate that way. It wanted to save the full path name to the file, and it could not do so because the path name length was over 260 characters. So the files never got backed up. Even windows would refuse to dig deep enough (file explorer) because file explorer keeps the accumulated path as you dig deeper into something like this. File Explorer, though, has to accommodate network paths, so the 260 character limit does not apply. But even File Explorer has its limits. It couldn't get to the files either.

So, you can define the result of a function like getfullpathname() as being 320 characters; it just won't be fully used.

https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry

Thanks bill for the clarification.

I am a bit puzzled by the meaning of 'path name' and 'file name' If the path name is limited to 260 characters and the file name to 256 characters, does this mean the full 'tree file name' can be 516 characters ? I can't recall problems with the 'full tree file name' using files@, but these are typically in system directories, where the files are not interesting !

I have just done a scan of my c: drive and largest tree name in c:\users is 239 characters largest tree name in c:\windows is 242 characters

All these long tree file names are system files.

The terms are confusing, very much so.

The file name refers to the name of the specific file without regard to its location within a folder.

The path name is both the file name AND the list of drive/folder(s) that, when traversed, will take you to the specific file.

And, no, it's not additive. 260 is the limit. Period. (with acknowledgement of UNICODE file names being longer).

Speaking of that, the windows API's that I deal with within FTN95 are all post-pended with the letter 'A', meaning it is the Ascii name. If you use the 'W' post-pended functions, then they are Unicode. It makes a BIG difference, and usually, only the 'A' functions are useful to English-only coding.

Sigh.

Yeah, really confusing.