folbricht/desync

Add a `--seed-and-data` option or something similar

RyuzakiKK opened this issue · 3 comments

RyuzakiKK commented

When using the --seed foo.caibx option, Desync expects to find the data in foo, next to the provided .caibx file.

While this is a valid assumption for files, it requires additional steps when the data is a block device. For example a common suggestion is to create a symlink next to the seed index.

I was thinking that maybe we could have an additional option, e.g. --seed-and-data, that takes the seed index and seed data in the same argument. Something like --seed-and-data /path/to/seed.caibx:/path/to/seed_data.

Another alternative could be to have ordered command line options?

Before implementing it, @folbricht I'd like to hear you opinion first.

folbricht commented

It's quite unfortunate that we need a new parameter for this, but I guess there's no real way to reuse the exiting --seed while maintaining 100% backwards compatibility. Would have been nice to do something like --seed file.caibx@somefile, or as in your case :.

Ordered command lines aren't pretty either. How about reading the seed data from a text file that has one line per seed like

file.caibx:data.bin:<perhaps other options in the future>

This could even be read from stdin if we wanted to.

RyuzakiKK commented

It's quite unfortunate that we need a new parameter for this, but I guess there's no real way to reuse the exiting --seed while maintaining 100% backwards compatibility. Would have been nice to do something like --seed file.caibx@somefile, or as in your case :.

I was thinking that maybe we could even do:

  • If the --seed value ends with .caibx, it is treated as a seed index path (as Desync does now). Its data will be searched next to it, without the .caibx extension.
  • If the --seed value has @ (or even .caibx@), split the argument at @. Then use the first part as the seed index path and the second as the seed data.

Given that --seed currently works only with paths that end with .caibx, this will not be a breaking change for compatibility.

(and do you prefer @ or :? Probably, as you mentioned, : is better to leave open the possibility for additional options in the future)

folbricht commented

I like it, let's use : as separator in that case.