-
Notifications
You must be signed in to change notification settings - Fork 121
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Modified DropOffUtil to put all file extensions in FILEXT #160
Modified DropOffUtil to put all file extensions in FILEXT #160
Conversation
In the case of multiple file extensions, should the last file extension be preserved as a separate value? |
That was not mentioned in the internal ticket. |
@@ -1019,12 +1019,12 @@ public void processMetadata(final List<IBaseDataObject> payloadList) { | |||
parentTypes.put("" + level, p.getFileType()); | |||
|
|||
final String fn = p.getStringParameter("Original-Filename"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I might be misinterpreting the ticket intent, but I understand it as handling multiple values in the Original-Filename parameter, more like:
final String fn = p.getStringParameter("Original-Filename"); | |
if (p.hasParameter("Original-Filename")) { | |
List<Object> fileNames = p.getParameter("Original-Filename"); | |
for (Object filename : fileNames) { | |
final String fn = (String) filename; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I re-read the issue and modified the code in dedf4c9
if (fext.length() > 0 && fext.length() <= this.maxFilextLen) { | ||
p.setParameter("FILEXT", fext.toLowerCase()); | ||
p.setParameter("FILEXT", fext); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the above comment re: multiple Original-Filename values is correct, this will need to change so the extensions from all Original-Filename values are preserved.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This has been addressed in dedf4c9
That's a good question, and probably needs clarification. My first instinct is that this (last extension) would be more aligned with how the data might be searched for. |
Re-reading issue it seems that maybe I misunderstood the original requirements. It seems "Original-Filename" may contain multiple file names. I was thinking the issue was with file extensions. I'll rework. |
Note that there is a change in the preserved file extension in this change. Prior to this change the code used the last occurrence of |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that there is a change in the preserved file extension in this change. Prior to this change the code used the last occurrence of
.
and this change uses the first. For a filefoo.tar.gz
the file extension prior to this change would have been.gz
and this change makes ittar.gz
.
Verbal feedback I've gotten from the original requestor is that this should continue to extract only after the last occurrence of .
. Same extraction as pre-PR, but now extracting the "last file extension" from each of the values stored under the "Original-filename" key
Addressed in d80fff0 |
if (fext.length() > 0 && fext.length() <= this.maxFilextLen) { | ||
p.setParameter("FILEXT", fext.toLowerCase()); | ||
if (p.hasParameter("Original-Filename")) { | ||
final List<String> extensions = new ArrayList<>(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Recommend extracting lines 1022:1034 to a new method.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the rationale for the recommendation? Is this duplicated elsewhere? Where you looking for an associated test for this block of code?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed that this method extraction would make the processMetadata
method more coherent, but I don't consider that a blocker for the PR. We see virtually the same pattern immediately after this FILEXT processing (https://github.com/NationalSecurityAgency/emissary/pull/160/files#diff-5e7393b5cf28de1fa844df12051fecba96c6962dcbf4aaa3be6b7c233677e410R1040-R1060 would also benefit from a similar method extraction).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just concerned about the overall length and complexity of processMetadata
. I believe extracting to method will make it more readable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Addressed in 78aa260
…curityAgency#160) * Modified DropOffUtil to put all file extensions in FILEXT Closes NationalSecurityAgency#159 * Fixed assert message * Guard against the position of the first period being the last character in the file name * Modified DropOffUtil to add a file extension for each entry in Original-Filename * Modified to only use last file extension when there are multiple extensions on a file * Move file extension extraction code to it's own method
Closes #159