easage list is quite noisy at the moment.

Planned changes:

• Introduce a --verbose flag
• Output only entry names if the verbose flag is not present
• Output the currently-outputted information if the verbose flag is present

For reference this is what easage list currently produces on a test BIG archive I have locally:

Archive:
  kind: BigF
  size: 218
  len: 2
  data start: 0x36
Entries:
  test/b.txt
    offset: 0x36
    len: 20
  test/a.txt
    offset: 0x4a
    len: 144

ab256a1 added a TODO that this ticket covers.

The writer module's pack_directory function will want to take in a settings/options/configuration/etc. struct that contains a EntryOrderCriteria enum variant.

pub struct Settings {
    entry_order_criteria: EntryOrderCriteria,
}

pub enum EntryOrderCriteria {
    Length,
    Path,
}

Hello, can you let this command to print out a log file ?

Test case:

Original ControlBar.wnd from WindowSource

└> cat WindowSource/ControlBar.wnd | md5sum
325877c142f77f6f7c2b89756c709bd2  -

ControlBar.wnd packed by FinalBIG and extracted by easage unpack

└> cat WindowFinalBigOut/ControlBar.wnd | md5sum
325877c142f77f6f7c2b89756c709bd2  -

ControlBar.wnd packed by easage pack and extracted by easage unpack

└> cat WindowEasageOut/ControlBar.wnd |md5sum
9d8ee3949c812da38ce5267534d4858f  -

easage list data start: offset differs

$ ./easage list window-easage.big
Archive:
  kind: BigF
  size: 1994438
  len: 7
  data start: 0x139
Entries:
  Window/Menus/MapSelectMenu.wnd
    offset: 0x139
    len: 60534
  Window/Menus/LanMapSelectMenu.wnd
    offset: 0xedaf
    len: 68064
  Window/Menus/SkirmishGameOptionsMenu.wnd
    offset: 0x6d798
    len: 929866
  Window/ControlBar.wnd
    offset: 0x10bd5
    len: 351194
  Window/Menus/WOLMapSelectMenu.wnd
    offset: 0x10b19
    len: 68120
  Window/Menus/SkirmishMapSelectMenu.wnd
    offset: 0x10b51
    len: 68252
  Window/Menus/OptionsMenu.wnd
    offset: 0x55d13
    len: 448095


$ ./easage list window-finalbig.big

Archive:
  kind: BigF
  size: 1994435
  len: 7
  data start: 0x135
Entries:
  Window\Menus\MapSelectMenu.wnd
    offset: 0x666f0
    len: 60534
  Window\Menus\OptionsMenu.wnd
    offset: 0x75366
    len: 448095
  Window\ControlBar.wnd
    offset: 0x136
    len: 351194
  Window\Menus\SkirmishMapSelectMenu.wnd
    offset: 0x1c5a0f
    len: 68252
  Window\Menus\LanMapSelectMenu.wnd
    offset: 0x55d10
    len: 68064
  Window\Menus\WOLMapSelectMenu.wnd
    offset: 0x1d64ab
    len: 68120
  Window\Menus\SkirmishGameOptionsMenu.wnd
    offset: 0xe29c5
    len: 929866

Attachment

Includes x64 linux and windows easage

easage-bigf.zip

As discussed on IRC and in #8:

I'd like to suggest defaults for easage-pack under current functionality should be to target BIGF by default, and to list by path rather than lenght/file size. (finalbig behaviour)

This would make

easage pack --source foo --output bar.big

be equivalent to

easage pack --kind BIGF --order path --source foo --output bar.big

It's worth a mention that completions are available on windows (#25)
but I think setting defaults for the most common use case is still the norm in archivers.

https://github.com/blog/2111-issue-and-pull-request-templates

• PR template
• Issue template

Conversation from IRC:

14:04:13 triatomic recently updated to latest windows 10 via fast ring image 
14:04:18           esage binary throwing me a dependency error 
14:04:23           VCRUNTIME140.dll 
14:04:47           its weird cause i believe i didn't have that on older windows 10 :( 
14:05:09 @Phrohdoh hm, give me a moment 
14:05:27 triatomic this is the CLI version 
14:05:48 @Phrohdoh Are you able to determine which version of the vcruntime you currently have installed? (probably via the Control Panel) 
14:06:22 triatomic last one installed is 2015 
14:06:24 @Phrohdoh Or possibly query the registry: https://blogs.msdn.microsoft.com/astebner/2010/05/05/mailbag-how-to-detect-the-presence-of-the-visual-c-2010-redistributable-package/
14:06:51           Well, I'm more wondering if you have the x86 or x64 version installed. 
14:07:10 triatomic (x86) 
14:07:46           ok gona install the (x64) 
14:07:49 @Phrohdoh Would you install the latest x64 https://support.microsoft.com/bn-bd/help/2977003/the-latest-supported-visual-c-downloads and see if that changes anything? 
14:08:24 triatomic worked :D 
14:08:34 @Phrohdoh Great! 
14:08:47 triatomic usually when i install AOEII:HD it installs those
14:09:36 @Phrohdoh BTW did you install the 2015 or 2017 version just now? 
14:09:45 triatomic 2015 (x64) 

We should create a wiki page with errors and associated resolutions starting with this one.

Error

The code execution cannot proceed because VCRUNTIME140.dll was not found.
Reinstalling the program may fix this problem.

Resolution

Install the 64-bit VC++ runtime (in this case the 2015 version is a known-working version).

$ ./easage unpack --output out --source foo.big --names 'Data/INI/GameData.ini'

error: The argument '--names <names>...' cannot be used with one or more of the other specified arguments

USAGE:
    easage unpack --output <output> --source <source> <--names <names>...|--all>

For more information try --help

From IRC:

@Phrohdoh │ teteros: oh huh
        ⤷ │ that is talking about a mutually exclusive arg
        ⤷ │ maybe a bug in clap
  teteros │ hm
@Phrohdoh │ https://github.com/Phrohdoh/easage/blob/b743a234921720198c0c15b4276e9542b0415b5b/src/bin/easage_unpack.rs#L30-L38
@Phrohdoh │ Also it looks like there is a logic bug in
          │ https://github.com/Phrohdoh/easage/blob/b743a234921720198c0c15b4276e9542b0415b5b/src/bin/easage_unpack.rs#L50-L54

SAGE games like Generals can default their installation to C:\Program Files or C:\Program Files (x86) on x64 systems which you need UAC/Administrator privilidges to write for.

easage will fail if it does not have a "Run as Administrator" compatibility flag set, or is not elevated in other ways with I/O errors such as:

on easage pack

and

on easage unpack

We should let the user know why reading/writing is failing and possibly offer to elevate permissions (UAC Yes/No prompt) if easage detects it has no read/write permissions in output folder.

A quick note from IRC:

there is a table of entry infos after the BIG header that has to be adjusted (which means the offsets in said table all need to be changed because the size of the table will change)

This also means the entire file has to be re-written.

• Automatically compile all PRs
• Automatically test all PRs
• Automatically deploy native binaries to GitHub when new a tag is pushed

Types to document:

• Archive
• EntryInfo
• Kind
• Error
• Result

Guides to write:

• Reading an archive from disk
• Creating an archive from a directory

Documentation for failure on docs.rs.

https://github.com/Phrohdoh/easage/blob/34ce982f01d1f716a945c2946faeb2bb9a509074/src/bin/easage_unpack.rs#L50
https://github.com/Phrohdoh/easage/blob/91328477b4a0bffff807681ec6a7950bbf6468da/src/writer/mod.rs#L56

This is a regression introduced by 11d2c2f.

We are calculating these values based on the absolute path to the to-be-packed files instead of their path with the prefix stripped.

cc @Teteros (just so you know that using the --strip-prefix parameter will currently produce invalid BIGs)

The wiki page mentioned in the title is: https://github.com/Phrohdoh/easage/wiki/Runtime-issues-&-solutions

See discussion here.

Here are the instances of 'extract' in the codebase.

This is currently not possible via gtk-rs because the necessary functions are not implemented.

Reference material:
https://en.wikibooks.org/wiki/GTK%2B_By_Example/Tree_View/Sorting#GtkTreeSortable

BIG archives made on Windows currently do not retain directory trees on Unix-like machines.
Backslashes \ are not converted to directories / (on e.g. linux) essentially.

Test case:

On Windows

mkdir foo & echo baz >foo\bar & easage pack --source foo --output foo.big

On Linux

easage list foo.big
Archive:
  kind: Big4
  size: 50
  len: 1
  data start: 0x2b
Entries:
  foo\bar
    offset: 0x2b
    len: 7

└> easage extract --output . --source foo.big
└> ls -la
total 8
drwxr-xr-x  2 tete tete  80 Oct 23 13:34  .
drwxrwxrwt 10 root root 320 Oct 23 13:33  ..
-rw-r--r--  1 tete tete   7 Oct 23 13:34 'foo\bar'
-rw-r--r--  1 tete tete  50 Oct 23 13:27  foo.big

Expected: foo/bar

i.e. bar in folder called foo

The opposite works however

BIG archives created on Linux with easage pack will extract on Windows machines with folder paths respected.

foo.big with \ paths attached below

(wrapped in .zip due to github attachment support)
foo.big.zip

Currently we only support 'packing' a directory recursively.

Ideally a user of the library would be able to pack any (name, data) items into an archive.

Possible function signatures (not the only options though!):

pub fn pack(items: Vec<(String, &[u8])>, settings: Settings) -> Result<Archive>;
pub fn pack(items: Vec<(String, &[u8])>, settings: Settings) -> Result<Vec<u8>>;
pub fn pack(buf: &mut [u8], items: Vec<(String, &[u8])>, settings: Settings) -> Result<usize>;

At this point library users could pack from a (collected) TCP stream if they felt so inclined.

Note: This will make unit testing the contents of an Archive simple (ref #38).

Currently you can only change BIG format to use for packing only at compile time.
https://github.com/Phrohdoh/easage/blob/master/src/bin/easage_pack.rs#L35

A runtime easage pack option to pick the BIG kind to pack into would be more user friendly.

ref: #15