Bagger does not correctly escape filenames with newline characters in the manifest about bagger HOT 12 CLOSED

Hi @nkrabben
I am curious, what kind of files are you trying to bag that contain \r?

from bagger.

Could you also provide a sample file or a set of directions to reproduce the issue?

from bagger.

The files are Mac Icon files from a born-digital collection that we're processing.

Apparently, it's fairly common for their file names to end with \r although from the sample we're looking at, it's not consistent. Since it's a problem with the file name and not the content, I've been creating test files through bash.
touch "Icon^M"

from bagger.

Looks like this is due to the underlying bagit-java library which should be percent encoding the filename and decoding it when verifying. See LibraryOfCongress/bagit-java#51

from bagger.

@nkrabben take a look at https://github.com/LibraryOfCongress/bagger/releases/tag/v2.7.1 it should fix your problem.

from bagger.

Bagger 2.7.1 is crashing before it finishes loading. I get a few different errors.
Loading from the command line I get
Error: Could not find or load main class 2.
Loading from Finder I get
An illegal state occured.

I can still load 2.7.0

from bagger.

Sorry, I was impatient and built it without all the dependencies. I deleted the old version on the releases page and uploaded the new file. I also included the MD5 and SHA1 checksum so you can test and make sure you have the right version.

from bagger.

New error
Could not find or load main class 3

from bagger.

Really? I just tried running it and it was fine. Did you delete the old one? Could you add the log files so I can see exactly what happened?

from bagger.

Looks like it was my error. Deleted everything and Bagger loaded fine.

While testing the filename handling, I noticed a new edge case. Bagging a folder that contains "Icon\r" works as expected, but adding "Icon\r" directly to the payload gives the following error:
Error adding bag file: ~/Desktop/Icon
due to:
Can't read ~/Desktop/Icon

from bagger.

It looks like it is a bug in the JDK rt.jar supplied code. Specifically BasicFileChooserUI's inner class ApproveSelectionAction. The code is repeated here for easy viewing:

if (filename != null) {
    // Remove whitespaces from end of filename
        int i = filename.length() - 1;

        while (i >=0 && filename.charAt(i) <= ' ') {
            i--;
        }

        filename = filename.substring(0, i + 1);
}

This code as the comment suggests removes any whitespace at the end of a file name. In this case that is not the correct behavior. I will try and file a bug with the Java developers and post a link here.

from bagger.

Oracle has created a bug based on my report
http://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8160540

from bagger.