burdenc/filepak

Pack files into one resource

filepak's Issues

Potential memory leak in libPAK

CppCheck is saying that the DIR *dir is deleted incorrectly on line 76 of filePAK.cpp. I've tried different things, but I can't get it to stop giving me the error.
"filePAK.cpp: line 76: Mismatching allocation and deallocation: dir"

File size estimation goes haywire after opening a PAK and making changes

After opening an existing PAK file, the PAK file estimation is correct initially, but if the user tries to uncheck and/or recheck any of the entries, the size estimation becomes entirely wrong. The incorrect estimation continues to affect the accuracy of all subsequent estimations throughout the remaining running time of the program.

Problems with packing pak in itself

If you try appending the pak file you have open to itself you can get errors.

pakEXE is not what it should be

PakEXE is currently nothing more than a debugging tool for libPAK. It needs to be fleshed out into a fully functional, user-friendly, command-line interface for libPAK. It should be able to do all of the things that pakGUI can do, or at least most of them.

See pakEXE branch.

A checksum system is needed

Since PAK files will be able to hold TBs of data we should add some sort of checksum system to ensure the data isn't corrupted. The checksum could be stored in the header. I've already included a error code to denote that there's a bad checksum (PAK_BAD_CHECKSUM).

libPAK does not have sufficient commenting.

libPAK needs commenting in a few more places, specifically libPAK.cpp, before release.

Sometimes drag&dropping large files causes pakGUI to freeze

If you attempt to add a significantly large file (~2GB+), the program takes longer than it should to add the file and/or the program will completely freeze. This only seems to occur when dragging and dropping files, though this has not been confirmed.

libPAK needs to be thoroughly tested on unix systems

So far all testing has been done on Windows, though the only thing I forsee causing problems is the different dirent classes (which should be handled by the #ifndef POSIX).

libPAK needs optimization

Specifically with the rebuildPAK function as it currently output to a "filename.pak.new" then replaces the old one.

Add Files button needs an implementation

The Add files button needs to be implemented.

Error log doesn't start scrolled to the bottom

When you open the error log dialog, the text box should start out scrolled to the bottom.

pakEXE should explicitly link (DLL) with libPAK

PakEXE should be linking with libPAK by explicit linking (linking with a DLL instead of a LIB file).
As soon as I figure this out with pakGUI, I'll let you know how.

Disclaimer: I'm not sure yet if explicit linking is the right way to do it with pakEXE, but my initial determination is yes, it should. We may release two different versions of pakEXE.

Makefile needs to be created for Linux release

There needs to be a makefile created for the Linux release.

Make createPAK only create an empty PAK file

This will allow the library to worked with easier and allow for taking out duplicate code blocks that had to be made. Once this is done you will need to create a new PAK file (i.e. give it a name and encryption type) then read it and then add things to it.

pakGUI controls need tooltips

The controls of pakGUI need helpful tool tips to explain what each action does.

PAKfileEntry needs to be it's own class rather than a struct

This will then allow us to have one function for all PAKfileEntry stuff that just returns the struct instead of multiples for the data, size, etc.

So you would get the PAKfileEntry object and you can then tell it to load the data, etc. This will require the each object having a pointer to the libPAK object that it resides in.

pakGUI's PAK'ing is not implemented

PAK'ing/RePAK'ing in pakGUI is not yet implemented.

Multiple and better encryption algrorithms

We need better encryption algorithms with a way to choose which one you wish use in the PAK. Possibly also a way to change the algorithms after the PAK has been made.

pakEXE does not have sufficient commenting.

pakEXE needs to be commented much more before release.

pakGUI does not have sufficient commenting.

pakGUI needs additional commenting in several places before release.

Main window does not allow resizing

The main window of the program does not allow resizing due to lack of dynamic control resizing and relocation. This was initially by design but has become an issue.

Possibly create a seperate library for only reading files

The reading functions are what games/applications are mostly going to be using while their games are running, and use the creation/editting functions right before release (because they can just use the raw file data instead of a pak while testing it). So I propose we make a separate light weight library for only reading file data.

The solution's configurations need to be cleaned up

Before release of Version 1.0, the solution's Release and Debug configurations need to be altered in order to prepare them for a release. The solution needs much better output file organization. All configuration options need to be carefully reviewed to see if the user will benefit from a change in that option.
LibPAK needs both static library and dynamic library output configurations.

Most if not all bool returning functions need to return int

This way we easily return why a function failed, possibly to say that you're trying to add a file that already exists in the PAK, or an output stream couldn't be opened. Obviously since 0 equates to false this shouldn't change a whole lot of calls to functions

Error log dialog position isn't reset upon display

The error log's dialog position isn't reset every time it's displayed. This can cause a problem if the dialog is off-screen when closed and the user tried to reopen it.

Sorting the file list does not work

Attempting to sort the file list by clicking on the column head does not work. This feature lacks an implementation.

Adding a file too large causes the file size to be calculated wrong

If you add a large file (~2GB+) the file size will be calculated completely wrong. Sometimes the size will be MUCH larger than the actual size (15GB seems to be a recurring number), or it'll be MUCH smaller than the actual size. It doesn't quite seem like an overflow error, but something is fishy here.

Adding too many files results in the estimated size to be miscalculated

Adding too many files to the list causes the Estimated Size after PAK to be miscalculated (resulting in 1KB every time). I believe this is due to the currentEstimatedSize variable overflowing since it keeps track of the bytes and it's only of type long.

pakGUI and pakEXE need executable icons

Before releasing version 1.0, pakGUI needs an icon for its executable, and the command line front-end for libPAK (currently named pakEXE) would ideally have a unique icon as well.

Associate PAK files with pakGUI in Windows

We need give an option to associate the .pak extension with pakGUI in Windows.

Sorting by the file size column doesn't work

If you attempt to sort the list using the file size column, it only sorts by the numbers. It does not take the unit into account.
In other words, a 5KB item will appear above a 1GB item when sorted in ascending order.

pakGUI uses a hard-coded version of libPAK

PakGUI uses a hard-coded version of libPAK. This means any changes to the back-end (libPAK) must be implemented twice. Very counter-intuitive and counter-productive.
Planning to link to a libPAK DLL, but early attempts created many problems.

Something is funky with including relative paths in pakEXE

Try this:
run pakEXE
Create PAK
Enter any pak name I used "./blah.pak"
Enter "./" for the include directory.
It placed blah.pak in the current directory, but it included "C:" instead of the current directory, and then, it only included 4 of the 27 files I had in "C:"

Unhandled exception sometimes when adding files.

I added a directory and clicked the list while it was adding the files, and got an exception:

************** Exception Text **************
System.ArgumentOutOfRangeException: StartIndex cannot be less than zero.
Parameter name: startIndex
at System.String.InternalSubStringWithChecks(Int32 startIndex, Int32 length, Boolean fAlwaysCopy)
at System.String.Substring(Int32 startIndex)
at PAKGUI.frmMain.btnBrowseDir_Click(Object sender, EventArgs e) in c:\users\drew\documents~code\filepak\pakgui\btnevents.cpp:line 490
at System.Windows.Forms.Control.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ButtonBase.WndProc(Message& m)
at System.Windows.Forms.Button.WndProc(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

Dragging and dropping with folders has adverse effects

Dragging and dropping a folder does not work at all (this is not necessarily a bug). The real bug is that if you drag and drop a collection of files that contains a folder, it will not add all the files to the list. I believe this might be because the function gives up as soon as it encounters a folder.
This does not seem to be an issue when clicking the "Add Directory" button.