should opening a second channel with TRUNCATE_EXISTING use a new file header?

[overheadhunter]

On CI (not reproducible on all setups, though) testTruncateExistingWhileStillOpen fails.

Due to TRUNCATE_EXISTING flag being passed through to the ciphertext file channel, the ciphertext file size is reset to zero as soon as the method is invoked, which causes a new header to be created:

cryptofs/src/main/java/org/cryptomator/cryptofs/fh/OpenCryptoFile.java

Lines 68 to 87 in e1704e8

	public synchronized FileChannel newFileChannel(EffectiveOpenOptions options, FileAttribute<?>... attrs) throws IOException {
	Path path = currentFilePath.get();
	if (options.truncateExisting()) {
	chunkCache.invalidateAll();
	}
	FileChannel ciphertextFileChannel = null;
	CleartextFileChannel cleartextFileChannel = null;
	try {
	ciphertextFileChannel = path.getFileSystem().provider().newFileChannel(path, options.createOpenOptionsForEncryptedFile(), attrs);
	final FileHeader header;
	final boolean isNewHeader;
	if (ciphertextFileChannel.size() == 0l) {
	header = headerHolder.createNew();
	isNewHeader = true;
	} else {
	header = headerHolder.loadExisting(ciphertextFileChannel);
	isNewHeader = false;
	}

I'm currently unsure, if this is desirable behaviour (and the test is broken) or the existing header should really be kept.

[overheadhunter]

As already specified in #48: Yes TRUNCATE_EXISTING should generate a new header. However FileHeaderHolder will only generate a header once due to this atomic CAS operation:

cryptofs/src/main/java/org/cryptomator/cryptofs/fh/FileHeaderHolder.java

Lines 39 to 47 in e1704e8

	public FileHeader createNew() {
	LOG.trace("Generating file header for {}", path.get());
	FileHeader newHeader = cryptor.fileHeaderCryptor().create();
	if (header.compareAndSet(null, newHeader)) {
	return newHeader;
	} else {
	return header.get();
	}
	}