`InMemoryOnDiskCorpus::with_meta_format_and_prefix` does not actually add a prefix to files

[EliaGeretto]

It looks like the prefix field of InMemoryOnDiskCorpus can be set using with_meta_format_and_prefix, but it is actually never used to compose the name of the corpus files as the documentation states. The same holds for OnDiskCorpus::with_prefix, which offloads that functionality to this struct.

LibAFL/crates/libafl/src/corpus/inmemory_ondisk.rs

Lines 55 to 65 in fb5772e

	/// A corpus able to store [`Testcase`]s to disk, while also keeping all of them in memory.
	///
	/// Metadata is written to a `.<filename>.metadata` file in the same folder by default.
	#[derive(Default, Serialize, Deserialize, Clone, Debug)]
	pub struct InMemoryOnDiskCorpus<I> {
	inner: InMemoryCorpus<I>,
	dir_path: PathBuf,
	meta_format: Option<OnDiskMetadataFormat>,
	prefix: Option<String>,
	locking: bool,
	}

It looks like the prefix field was added as part of #981 but never completely implemented.

[rmalmain]

i am in the middle of refactoring for this part of the code (#3159). this specific function will most likely disappear.
i was planning to add a callback to set the metadata format, and remove prefix.
is it something you need or plan to use?

fyi the wip relevant part is there.

[EliaGeretto]

So, to clarify, I am working on a fuzzer that has custom components for mutators and similar, but needs to behave like LibFuzzer to ease the integration into our fuzzing infrastructure. I stumbled upon this issue because I was adding support for -artifact_prefix=, which allows you to specify both the directory for the objectives and a prefix for their filename, e.g., -artifact_prefix=abc/def- will create a def-<suffix> file in directory abc.

Apart from this, there is the whole issue of naming the files according to their ExitKind, so crash-XXX, oom-XXX, etc. Looking at your refactored code, the filename is determined exclusively by the test case id, so I assume supporting both -artifact_prefix and ExitKind-based names would require a custom LibFuzzer Store anyway. Am I correct?

Still, implementing this LibFuzzer Store seems significantly easier after this refactoring because only the Store is responsible to know where things are on disk and there is no file path member in Testcase anymore. Is this the intended solution for my use case after your refactoring?

[atharva-potdar]

Does #3630 close this?