Mail Archives: djgpp/2012/08/22/21:45:33
<rugxulo AT gmail DOT com> wrote in message
news:0767c622-615f-42ed-bb35-ebeef4268974 AT googlegroups DOT com...
> On Tuesday, August 21, 2012 1:52:12 AM UTC-5, Rod Pemberton wrote:
...
> > [www.bttr-software.de]
>
> I really only expected a few random testers there.
I don't have an account there. Seems you need apply for and be approved by
someone.
> > Also, you'll probably need or want some of DJGPP's CRT0 flags to be
> > added in files with C's main():
> >
> > #ifdef DJGPP
> > #include <crt0.h>
> > int _crt0_startup_flags = _CRT0_FLAG_USE_DOS_SLASHES;
> > #endif
>
> [...]
> > Those will help pass DOS path's correctly.
>
Sorry, you probably didn't need the preserve quotes one.
> It's honestly too dangerous to mess with. I don't want to call p7zip a
> sloppy port (from Win32 to POSIX), but it's not something I'm comfortable
> with. Anyways, even now, it still won't recognize a file such as BLAH.7Z,
> but blah.7z works fine (go figure).
I'm assuming you mean it's accepting the LFN "blah.7z" but not the SFN
"BLAH.7Z" when LFNs are active? SFNs are uppercase 8.3. Lowercase
is LFN even if only 8.3... Yes, by default, you can use one or the other,
either LFN or SFN, not both.
You can add code which allows both, but that may be a bit much. Typically,
I'll setup for using LFNs and then get SFNs for the LFNS. I.e., two DPMI
calls: one to detect LFN and the other to convert LFNs to SFNs, the set of
CRT0 flags, forcing use of LFN if detected with another CRT0 flag and
setenv(), etc.
> And that's without "preserving" or "keeping uppercase" anything!
> So I dunno, minor nit.
Are you saying you _did_ or _did not_ try the preserve uppercase and
filename CRT0 flags?
Let me review them...
I'd think you definately want, which you have:
_CRT0_FLAG_USE_DOS_SLASHES
If it uses file or path from argv[0], you'd probably want:
_CRTO_FLAG_PRESERVE_UPPER_CASE
You'll have to check to see if you need:
_CRT0_FLAG_PRESERVE_FILENAME_CASE
From the description, that flag will either lowercase or uppercase names.
I'm not quite sure that's true. I think it lowercases names if reset and
preserves LFNs if set, i.e., I don't think it uppercases as claimed. IIRC,
the uppercase claim is just for SFNs. Personally, I suspect it's needed.
Drop a printf of the path into the code somewhere. Set it. Recompile.
Clear it. Recompile. See if anything changes. E.g., it might be
lowercasing names that it shouldn't be.
You'll probably want to leave the glob function alone for wildcards. I see
no need to mess with load function either.
> > HTH and hope you see this,
>
> Yes, it did help, not totally, but very very close. Thanks!!
>
> Though it's still not totally perfect. For instance, I still haven't
> bothered looking for or fixing the temporary file generation
> (e.g. updating existing archive), so it assumes LFNs, e.g. blah.7z.tmp ,
> which obviously doesn't work in SFN. A stupid workaround is to
> rename blah.7z to blah [sic], then do "7za d -r blah. *.c" [sic], and
> it should delete or update correctly (assuming you don't want to
> just use DOSLFN).
Here, I think you mean extracting the archive's saved non-DOS LFNs when DOS
is using SFNs or has LFNs disabled which would require SFNs to be created
for DOS from the archive's non-DOS LFNs. Yeah, that's a problem. The
solution may be a bit much too. It follows.
If you have LFN active, p7zip should work fine extracting saved non-DOS LFNs
to DOS LFNs. However, to allow it to work for DOS using both LFNs and SFNs,
the solution is to convert the archive's non-DOS LFNs to DOS compatible
SFNs. That requires a custom function to convert non-DOS LFNs to SFNs to
create an acceptable/recognizable SFN. Open, write, close to the created
SFN. Then, to support use of LFNs, detect if LFNs are active, and if it is,
then rename the created SFN to an LFN. So, if SFNs are in use, only SFNs
are created, but if LFNs are in use, SFNs are created and then renamed to
LFNs.
See here for an example of this:
https://groups.google.com/forum/?hl=en&fromgroups=#!topic/comp.os.msdos.djgpp/O8jQn1GbrmU
p7zip is much larger. It could be easy or difficult to fix.
Rod Pemberton
- Raw text -