search

aswaving / yenc

Encoding and decoding using yEnc encoding in Rust
MIT License
4 stars 4 forks source link

Added an override_filename option to the decoder. #15

Closed heksesang closed 2 years ago

heksesang commented 2 years ago

To be able to support yEnc-encoding with obfuscation of the filename, it must be possible to override the filename used when decoding with a given value.

I ran into this issue that, with such obfuscated filenames, my application would decode all the parts into separate files which made the result sort of useless (and at least on Windows would take a huge amount of space due to the data being written after a lot of null data in each file).

This PR adds a simple override_filename: Option<P> to the DecodeOptions which is used instead of the one parsed from the metadata if it is set to a value other than None.

aswaving commented 2 years ago

Why should there even be a filename overrule in the decode options? Why not, in your decode program, rename the resulting filename you get back from decode_stream or decode_file to the name you need?

heksesang commented 2 years ago

Why should there even be a filename overrule in the decode options? Why not, in your decode program, rename the resulting filename you get back from decode_stream or decode_file to the name you need?

The problem with that approach currently is that the data might be written to anywhere within that file. So if multiple parts are written to different files and the decode program renames the files, data will simply be overwritten.

Take this example:

  1. Data is written to foo.
  2. foo is renamed to baz.
  3. Data is written to bar.
  4. bar is renamed to baz

At 4) we run into the issue that the data from bar would overwrite the data from foo. But we could do this instead:

  1. Merge bar into baz.

Currently that is not possible because there is no metadata about where in the file data was written. So maybe we should rather return the metadata from the header from the decode_* functions? Then the decoding program can handle any such issues by itself.

But it might be best to make new functions in that case, to stay backwards compatible. Any idea to naming if we were to go with such an approach?

heksesang commented 2 years ago

Having thought more about it, I do think returning the metadata is better solution and more flexible than this (it leaves the decoding program with more information to use however it sees fit). So I'll close this PR and make a new one with those changes.