Bugs item #2816105, was opened at 2009-07-03 14:00
Message generated for change (Comment added) made by vombatus
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=577089&aid=2816105&group_id=85722
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 1
Private: No
Submitted By: Matthew Oliver (matthewoliver)
Assigned to: Nobody/Anonymous (nobody)
Summary: Renaming of gzip and macbinary when exported from xena
Initial Comment:
When a gzipped or a macbinary file is normalised inside Xena then the actual binary file is stripped/uncompressed out of the container and that file is passed back into Xena for normalisation.
When you export the file back out of Xena the "stripped/uncompressed" binary is exported as expected, BUT it is named "<input dataobject name>.<normalised extension>".
E.g: some_image.jpg.gz -> some_image.jpg.gz.jpg
This is caused by the original dataobject name being carried across, tho this isn't necessarily a bug, if the file that is extracted cannot be normalised and so is binary normalised then it doesn't get an extension.
E.g: some_binary.gz -> some_binary.gz
The exported file shares the same name as the original BUT the exported is actually, in the above case, the unzipped version and not a gzipped file at all.
Like the subject says I have noticed this behavior with gzip and macbinary files, and there very well could be more.
I have added this to the bug system so this limitation is documented.
----------------------------------------------------------------------
>Comment By: John (vombatus)
Date: 2009-07-03 14:25
Message:
Matt
There is also a DPR Feature request on the better treatment of files
inside 'container' files (archives, mailboxes and the like)
https://sourceforge.net/tracker/?func=detail&aid=2039768&group_id=116934&atid=676459.
If you solve one, you might solve the other
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=577089&aid=2816105&group_id=85722

Bugs item #2816105, was opened at 2009-07-03 14:00
Message generated for change (Tracker Item Submitted) made by matthewoliver
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=577089&aid=2816105&group_id=85722
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 1
Private: No
Submitted By: Matthew Oliver (matthewoliver)
Assigned to: Nobody/Anonymous (nobody)
Summary: Renaming of gzip and macbinary when exported from xena
Initial Comment:
When a gzipped or a macbinary file is normalised inside Xena then the actual binary file is stripped/uncompressed out of the container and that file is passed back into Xena for normalisation.
When you export the file back out of Xena the "stripped/uncompressed" binary is exported as expected, BUT it is named "<input dataobject name>.<normalised extension>".
E.g: some_image.jpg.gz -> some_image.jpg.gz.jpg
This is caused by the original dataobject name being carried across, tho this isn't necessarily a bug, if the file that is extracted cannot be normalised and so is binary normalised then it doesn't get an extension.
E.g: some_binary.gz -> some_binary.gz
The exported file shares the same name as the original BUT the exported is actually, in the above case, the unzipped version and not a gzipped file at all.
Like the subject says I have noticed this behavior with gzip and macbinary files, and there very well could be more.
I have added this to the bug system so this limitation is documented.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=577089&aid=2816105&group_id=85722