From bertolaccinifrancesco at gmail.com  Thu Jun 15 13:57:33 2017
From: bertolaccinifrancesco at gmail.com (Francesco Bertolaccini)
Date: Thu, 15 Jun 2017 19:57:33 +0200
Subject: [physfs] Unpacked file format with long paths
Message-ID: <CAL3FrgB-60ieMU6zCWoJ6KMnbc3LRyVLoGLQZfv0sWpr2AcnyQ@mail.gmail.com>

Hi everyone,
I am currently writing a loader for an archive which uses - as usual - an
unpacked format. The only problem is that the pathnames may exceed 64
bytes, and this poses a problem because it goes against the "rules" stated
in the physfs source. But: it also mentions that those rules can be relaxed
as necessary.

So, is it possible to use the unpacked utilities with filenames longer than
64 bytes, or do I have to rewrite all those just to have more headroom?

Cheers,
Francesco Bertolaccini
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://icculus.org/pipermail/physfs/attachments/20170615/84c748fa/attachment.html>

From icculus at icculus.org  Thu Jun 15 15:53:37 2017
From: icculus at icculus.org (Ryan C. Gordon)
Date: Thu, 15 Jun 2017 15:53:37 -0400
Subject: [physfs] Unpacked file format with long paths
In-Reply-To: <CAL3FrgB-60ieMU6zCWoJ6KMnbc3LRyVLoGLQZfv0sWpr2AcnyQ@mail.gmail.com>
References: <CAL3FrgB-60ieMU6zCWoJ6KMnbc3LRyVLoGLQZfv0sWpr2AcnyQ@mail.gmail.com>
Message-ID: <30638827-df09-1d5c-13a3-9fd6578674be@icculus.org>


> So, is it possible to use the unpacked utilities with filenames longer 
> than 64 bytes, or do I have to rewrite all those just to have more headroom?

Do you have a maximum in mind? The 64 char limit is because metadata 
gets stored in a struct like this:

     typedef struct
     {
         char name[64];
         PHYSFS_uint32 startPos;
         PHYSFS_uint32 size;
     } UNPKentry;

...the 64 bytes limit is because nothing currently _can_ use more (.slb 
files are 63 bytes plus a null char at most). But we just need to bump 
that number higher and recompile, unless your maximum is 0xFFFFFFFF 
chars or something, in which case we'll need to dynamically allocate this.

--ryan.


From sik.the.hedgehog at gmail.com  Thu Jun 15 20:56:15 2017
From: sik.the.hedgehog at gmail.com (Sik)
Date: Thu, 15 Jun 2017 21:56:15 -0300
Subject: [physfs] Unpacked file format with long paths
In-Reply-To: <30638827-df09-1d5c-13a3-9fd6578674be@icculus.org>
References: <CAL3FrgB-60ieMU6zCWoJ6KMnbc3LRyVLoGLQZfv0sWpr2AcnyQ@mail.gmail.com>
 <30638827-df09-1d5c-13a3-9fd6578674be@icculus.org>
Message-ID: <CAEyBR+UcmDZ-4f=bsxe6CGD16HBmijf9DRrP8+J10kPsdn3LHQ@mail.gmail.com>

2017-06-15 16:53 GMT-03:00, Ryan C. Gordon <icculus at icculus.org>:
>      typedef struct
>      {
>          char name[64];
>          PHYSFS_uint32 startPos;
>          PHYSFS_uint32 size;
>      } UNPKentry;

Are there arrays of those structs or the like? Because if not (i.e.
doesn't matter if their size isn't fixed), you could just move name to
the end and change it to name[0] (or name[1] if it gets nasty), then
allocate as many extra bytes as needed for holding the name.

Otherwise yeah you'll run into the need for dynamic allocation.
Meanwhile you could change it to 256, I suppose.

From bertolaccinifrancesco at gmail.com  Fri Jun 16 03:12:49 2017
From: bertolaccinifrancesco at gmail.com (Francesco Bertolaccini)
Date: Fri, 16 Jun 2017 09:12:49 +0200
Subject: [physfs] Unpacked file format with long paths
In-Reply-To: <CAEyBR+UcmDZ-4f=bsxe6CGD16HBmijf9DRrP8+J10kPsdn3LHQ@mail.gmail.com>
References: <CAL3FrgB-60ieMU6zCWoJ6KMnbc3LRyVLoGLQZfv0sWpr2AcnyQ@mail.gmail.com>
 <30638827-df09-1d5c-13a3-9fd6578674be@icculus.org>
 <CAEyBR+UcmDZ-4f=bsxe6CGD16HBmijf9DRrP8+J10kPsdn3LHQ@mail.gmail.com>
Message-ID: <CAL3FrgAEKxqBmc9aF+kfquehZGGu8KZRZRkZrkTxrtLFQS3U-A@mail.gmail.com>

I will give it a try, thank you.

Il 16 giu 2017 02:56, "Sik" <sik.the.hedgehog at gmail.com> ha scritto:

> 2017-06-15 16:53 GMT-03:00, Ryan C. Gordon <icculus at icculus.org>:
> >      typedef struct
> >      {
> >          char name[64];
> >          PHYSFS_uint32 startPos;
> >          PHYSFS_uint32 size;
> >      } UNPKentry;
>
> Are there arrays of those structs or the like? Because if not (i.e.
> doesn't matter if their size isn't fixed), you could just move name to
> the end and change it to name[0] (or name[1] if it gets nasty), then
> allocate as many extra bytes as needed for holding the name.
>
> Otherwise yeah you'll run into the need for dynamic allocation.
> Meanwhile you could change it to 256, I suppose.
> _______________________________________________
> physfs mailing list
> physfs at icculus.org
> http://icculus.org/mailman/listinfo/physfs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://icculus.org/pipermail/physfs/attachments/20170616/9bd27c46/attachment.html>