dgets / ras Goto Github PK

En route to #12, it has become apparent that something is messed up with my recursion algorithm. It is resulting in the following stack trace:

java.lang.NullPointerException
	at MyArchive.unroll(MyArchive.java:201)
	at RAS.main(RAS.java:68)

The applicable code is where entryName appears in the following for loop:

		if (Debugging.UNROLL) {
			//list directory contents
			System.out.println(arcFileName + " contents:");
			for (String entryName : archiveContents) {
				System.out.println(entryName);
			}
		}

Fix it, detc...

In order to preserve our tree structure for embedded archive re-rolling, we're going to need MyArchive to be able to hold links to other MyArchive objects. An array of these object references within the data structure will, at this point, most likely suffice. It may turn out more efficient, or maintainable, to consolidate some of the archive entry data, if these end up becoming more complex.

This issue is a part of #8.

Method needs to be modified to accept a flag telling it whether or not to create the archive structure as it populates entryHash. This will allow it to be called from unroll(), saving a large amount of duplicated code. A renaming may be in order after this point.

At some point, implement a flag that will specify minimal space usage. It could be used in a variety of different circumstances that might occur in usage of this app; for instance, in the extraction of only a particular file, existing within a secondary sub-archive, it could ensure that only the correct archive tree is written to disk before recursion, as well as deleting sub-archives from disk after the correct contents are pulled from them.

Then again, maybe this is just a good default behavior... I think, at this point, that options for both would be good, as full expansion/extraction is a good default for testing purposes. We'll see what to do with it exactly when it's closer to a working program.

Got my own version working the way that I need it to. Time to remove the Apache version of Lister.

There really isn't any documentation yet; get javadoc completed for this project.

Code needs to be added to verify that there will be space available for the uncompressed/unarchived contents on the selected temporary partition. Probably a good idea at this point to also add a flag for the user to specify a particular partition instead of the system temporary directory, also.

How much crack was I on, when I decided to do things that way? Ugh.

Must've been in a daze when writing this particular method. It doesn't travel down the child archives properly.

This is a sub-issue for #9.

Add the capability to start expanding archives embedded within the others.

NOTE: this is going to require changing the data structure of MyArchive to support recursive entries (array of MyArchive, most probably). Going to be opening an issue for that immediately after this one.

After switching to a Windows 7 machine for development (yay hardware failure on the main dev box), Apache's commons compress library seems to be having issues finding the signature for a .tar.gz archive. Troubleshooting has indicated that this issue doesn't apply to a .zip archive, and that a decompressed, .tar version of the same test archive works with this code without any problems. Obviously, the .tar.gz decompressed without incident via gzip, so it doesn't appear that the archive compression should be the issue.

Need to read more in the library docs to see if this is a known issue on Windows (7).

It's been so long since I've worked with this project that I'm having a really hard time remembering where I left off in the rewrite... I think .zip was the one that was implemented, since .tar.gz & .tar.bz2 no workee yet. Either way, they're the ones to implement next, if we're trying to roughly follow in order of most common archival types...

Add code to clean up dingleberries in the temp directory after completion.