Thank you for the fixes! I originally failed to test a mingw build of dosbox with LFN support. The mingw build does work, and since the printf statement corrects the issue for you (VS build?), then it seems probable that the issue (first reported) was a compiler optimization bug.
On the other question on file size and date in star commander while its LFN option is turned on (no issue where it is turned off): I verified that the file sizes are not fully reported on screen, but actually the size is 2,147,483,647 (as shown via the file info menu item in star commander). If I may guess, I would think the issue would involve use of a 32-bit integer variable (since the file size is exactly the maximum value of a 32-bit integer) or even the size of the reported hard drive; however, it is not an issue in doszip commander as you noted. There is also a small chance that star commander is performing some low level access, but only where LFN is active.
Edit: confirmed that running a dos image in dosbox avoids the star commander issue of displaying the incorrect file size and date while LFN is active.
Found this blurb about star commander (unfortunately the beta source code is not released):
SC 0.90.02 beta (2012-01-27)
Changes since SC 0.90.01 beta:
Fix: Lots of bugs, caused by code restructuring and integer size problems.
It would be necessary to test SC 0.90.02 beta to verify that the file size issue was not inadvertently fixed in the latest beta release, although I'm not hopeful. However, the newest beta version is not available. Perhaps the poster who reported the bug could notify the star commander developer and request the newest beta version, especially since the issue doesn't occur in doszip commander. He may be able to provide clues, too.