OS/2, eCS & ArcaOS - Technical > Applications

LarsenCommander - new test version

<< < (9/11) > >>

Andi B.:
Interesting. But if I understand it correctly it should be fixed since a while. I can reproduce problems here even with ArcaOS5.1EN.

OTOH LarsenCommander doing the copy stuff a bit unusual so this may be another JFS problem others rarely encounter. Lcmd reads the file (in chunks if bigger than internal dynamic buffer) and writes it to target. So far so good. Then it reads in all EAs from source file and then writes the EAs to the target. This EA handling is strange when you see it the first time. Reading every EA name and data with dynamic size.... And I think the problem occurs when writting the EAs.

Unfortunately I didn't find a way on OS/2 to read and write all EAs of a file at once. These can be <64k anyway so no would be no problem on todays systems. Reading all these EA entries in a loop by name and values is a mess.

Lars:

--- Quote ---Interesting. But if I understand it correctly it should be fixed since a while. I can reproduce problems here even with ArcaOS5.1EN.
--- End quote ---
A workaround is in place if you use "read" and "write" Posix functions as these break up large transfers into multiple smaller transfers before they eventually invoke DosRead (DosWrite). The native OS/2 API call "DosRead" continues to suffer from JFS quirks and limitations. It's the IFS driver that is broken, not the DosRead API function.


EAs: DosQueryFileInfo, DosQueryPathInfo, DosSetFileInfo, DosSetPathInfo, "pInfo" pointing to EAOP2 structure:

Getting all EAS at once is done with info level = FIL_QUERYALLEAS = 4.
fpFEA2LIST pointer will point to list of all EAs queried, including their values. You will need to hop from one entry to the next following the oNextEntryOffset field (the individual FEA2s are varying in length). Provide a sufficiently large buffer in fpFEA2List (> 64k, better twice that size) so that it can be filled.

Setting all EAS at once is done with info level = FIL_SETEASFROMLIST = 2.
fpFEA2LIST pointer points to list of all EAS to set, including the values to set. Need to set the oNextEntryOffset to point to the next element (the individual FEA2s are varying in length). Provide a sufficiently large buffer in fpFEA2List (holding all your EAs). You have to ensure that you do not exceed maximum EA overall size.

These info levels are undocumented in the CPS.

You should be able to feed the result of FIL_QUERYALLEAS (read EAs with DosQueryXXXXInfo) into FIL_SETEASFROMLIST (write EAs with DosSetXXXXInfo).

DosEnumAttribute will give you a list of EAs (names) that exist. It's not really needed if you just make the EA buffer large enough (we know the maximum but take into account EA structure and EA name lengths, not only values).

Andi B.:

--- Quote ---These info levels are undocumented in the CPS.
--- End quote ---
Wow. Some of your explanations sounds familiar. After I invested countless hours on reading original Lcmd code, edm2 and all the help files of os2tk45. But where did you get the undocumented stuff from? Answers from some experts in some goups which you noted somewhere? Or is there a place where someone document such undocumented stuff? Stevens site?

Btw: these idiots which wrote the control programming appendum for DosOpenL f.i. should be sent to jail. Again I stumbled over this wrong description and examples (variables versus pointers). It's a mess when the official documentation is so wrong in so many places :-(.

Btw2: It's a somehow educated guess that the file system is faulty here. With different versions of EA handling in Lcmd I very often got 'Trap 000e in JFS'. The last implementation which I think perfectly correct, let the IFS silently stop working only sometimes. Unfortunately I need to copy a few hundred thousand files with a lot of GBs. So still have no simple scenario to reproduce.

Btw3: For my problem I think it's not the DosRead buffer size as this is already limited (<1 - ~16MB) here. AFAIK the problem Silvan reported happens with about 400MB and above. OTOH David explained in the ticket it's not the buffer size which triggers this one known problem, but 2 DosOpenL calls where the first one does nothing. Do you think Davids explanation in the ticket is wrong? Or is he talking about another problem? Is it worth to test with read buffers max. 1MB f.i.?

Lars:
Hi Andi,


--- Quote from: Andi B. on February 26, 2025, 08:37:02 am ---
--- Quote ---These info levels are undocumented in the CPS.
--- End quote ---
Wow. Some of your explanations sounds familiar. After I invested countless hours on reading original Lcmd code, edm2 and all the help files of os2tk45. But where did you get the undocumented stuff from? Answers from some experts in some goups which you noted somewhere? Or is there a place where someone document such undocumented stuff? Stevens site?

...

Btw3: For my problem I think it's not the DosRead buffer size as this is already limited (<1 - ~16MB) here. AFAIK the problem Silvan reported happens with about 400MB and above. OTOH David explained in the ticket it's not the buffer size which triggers this one known problem, but 2 DosOpenL calls where the first one does nothing. Do you think Davids explanation in the ticket is wrong? Or is he talking about another problem? Is it worth to test with read buffers max. 1MB f.i.?

--- End quote ---

For EAs: I looked into the OpenJFS Source code at netlabs.org and what it does. Needless to say that it does stuff that is not documented but I took it by the word (and hope HPFS does the same):

https://trac.netlabs.org/OpenJfs

and I looked at a very old OS/2 Version 1.2 IFS Specification written by Microsoft in 1989 that I found in the internet, it appears as part of European patent EP0415346A2:

https://patentimages.storage.googleapis.com/23/69/45/f6a4cb501938a9/EP0415346A2.pdf

it was scanned by someone from a pile of paper (and that I cleaned from junk and reprocessed as a new PDF to make it more accessible). Don't forget to scroll through it all the way !
I have no clue of why some of the info in the old IFS specification got lost along the way but on the other hand it covers stuff that is no longer relevant/workable, you need to be careful ...

In the old IFS spec, you can read the following for DosQFileInfo / DosQPathInfo:


--- Quote ---*** THE FOLLOWING UNPUBLISHED FUNCTION WILL GO AWAY IN FUTURE *****
*** RELEASES AND SHOULD BE UNPUBLISHED ***
Level 0x0004 file information returns all EA info for the file. On input, FileInfoBuf is an EAOP structure above. fpGEAList contents are ignored. fpFEAList points to a data area where the relevant FEA list will be returned. The length field of this FEA list is valid, giving the size of the FEA list buffer. offError is ignored.
...

--- End quote ---
Guess what, that info level never went away (translate "DosQueryFileInfo" for "DosQFileInfo"), likely because some app used it and then MS needed to continue supporting it :-)

Likewise for DosSetFileInfo / DosSetPathInfo:


--- Quote ---Level 0x0002 file information sets a series of EA name/value pairs. On input, PathInfoBuf is an EAOP structure above. fpGEAList is ignored. fpFEAList ponts to a data area where the relevant FEA list is to be found. offError is ignored.

--- End quote ---

I guess that by now, you get the idea :-)


For AN ticket: I no longer have access to the AN ticket system and therefore cannot see what they found out.



Andi B.:
Thank you very much. Enough stuff to test and try out. Have to bookmark this. OTOH I thought this lcmd version would be really the last one.....

Ouch, I don't have access to the source code at netlabs :-(.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version