Mail Archives: djgpp/2003/12/19/07:15:33
Eli Zaretskii wrote:
>>Date: Thu, 18 Dec 2003 13:13:51 +0100
>>From: Manuel Collado <m DOT collado AT aaron DOT ls DOT fi DOT upm DOT es>
>>Newsgroups: comp.os.msdos.djgpp
>>
>>
>>>>2. LFN support (I'm aware of _use_lfn. Any more?)
>>>
>>>What's wrong with _use_lfn? If you have specific problems with it,
>>>please ask specific questions.
>>
>>Please see below.
>
> I've read that, but I still don't understand why _use_lfn would not
> suffice. I think that is what you ned.
> ...
Well, after reading the libc docs again I think _use_lfn will do the
job. But the usage seems somehow tricky. I assume this is the relevant
doc fragment:
===
Return Value
------------
If LFN APIs are supported and should be used, it returns 1, else 0.
Note that if the `_CRT0_FLAG_NO_LFN' bit is set, or `LFN' is set to `N'
or `n' in the environment, both `_use_lfn' and `_USE_LFN' will always
return 0 without querying the filesystem. You can reset the
`_CRT0_FLAG_NO_LFN' bit at runtime to force filesystem to be queried.
===
So to detect the true LFN system capability one should:
- reset CRT0_FLAG_NO_LFN
- call _use_lfn
- restore CRT0_FLAG_NO_LFN to its previous value
Can this be done safely in the middle of a program execution?
_CRT0_FLAG_NO_LFN is a component of _crt0_startup_flags, and this name
suggest troubles if changes are intermixed with file (or other)
operations. What if there are open files while querying for LFN support?
Thanks,
--
To reply by e-mail, please remove the extra dot
in the given address: m.collado -> mcollado
- Raw text -