Certain operations are not atomic in respect to the lib consumer

[infeo]

As the library consumer, i expect, that no (access, timing)-pattern creates an invalid vault structure (TODO: define what this means).

This is not the case under certain conditions. As an example:
If a shortened file is simultaneously deleted and moved, there is a short timing window, where at the destination already files were created, but the actual content file is deleted. The move fails with an exception, but the residual files are not cleaned up.
Specifically, if the moving thread is put on hold before line 600, another thread can delete the content file (because in openCryptoFiles the mapping for the old path exists). Line 600 will fail, but the filesystem nodes created in the line before are not deleted.

cryptofs/src/main/java/org/cryptomator/cryptofs/CryptoFileSystemImpl.java

Lines 590 to 606 in b3755f3

	private void moveFile(CryptoPath cleartextSource, CryptoPath cleartextTarget, CopyOption[] options) throws IOException {
	// While moving a file, it is possible to keep the channels open. In order to make this work
	// we need to re-map the OpenCryptoFile entry.
	CiphertextFilePath ciphertextSource = cryptoPathMapper.getCiphertextFilePath(cleartextSource);
	CiphertextFilePath ciphertextTarget = cryptoPathMapper.getCiphertextFilePath(cleartextTarget);
	try (OpenCryptoFiles.TwoPhaseMove twoPhaseMove = openCryptoFiles.prepareMove(ciphertextSource.getRawPath(), ciphertextTarget.getRawPath())) {
	if (ciphertextTarget.isShortened()) {
	Files.createDirectory(ciphertextTarget.getRawPath());
	ciphertextTarget.persistLongFileName();
	}
	Files.move(ciphertextSource.getFilePath(), ciphertextTarget.getFilePath(), options);
	if (ciphertextSource.isShortened()) {
	Files.walkFileTree(ciphertextSource.getRawPath(), DeletingFileVisitor.INSTANCE);
	}
	twoPhaseMove.commit();
	}
	}

Another example is deleting a file, to which a new file channel is opened with the CREATE flag. TODO: elaborate once #170 is fixed.