Moving dirs/symlinks lead to error when Source and Target have shortened names

[infeo]

Moving a directory (or symlink) with a shortened name to a target, which name also needs to be shortend, makes the content of the dir inaccessible.

It is caused by the combination of the implenations of the moveDirectory(...) (or moveSymlink(...)) method and of the persistence method for the long name:

• excerpt of moveDirectory(...): https://github.com/cryptomator/cryptofs/blob/6c66842bbd9987e3352206c99e7640e9efe99b21/src/main/java/org/cryptomator/cryptofs/CryptoFileSystemImpl.java#L579-L584
• core persist method: https://github.com/cryptomator/cryptofs/blob/6c66842bbd9987e3352206c99e7640e9efe99b21/src/main/java/org/cryptomator/cryptofs/LongFileNameProvider.java#L116-L125 In moveDirectory(...), the whole directory is moved and if it shortend, we persist also the long name. But since the source has already a long name, also the long name file name.c9s already exists, such that the actual persist operation does nothing.

[overheadhunter]

I'd rather do this as a 2.0.x hotfix and maybe even backport it to 1.x

[infeo]

From my point of view there are two solutions:

1. Introduce a force flag to the "persist" methods
2. Change persistInternal method to always open the file channel

Since we do nothing in the FileAlreadyExistsException, I prefer solution 2 for its absolutly minimal changeset. The only worry is performance, but looking at the usages of persistsLongName(), nearly always name.c9r file needs to be created. The only exception are already existing files with shortened names. Everytime a filechannel is opened to such a file, persistLongName() is also called (but nothing a simple if cannot solve):

    private FileChannel newFileChannelFromFile(CryptoPath cleartextFilePath, EffectiveOpenOptions options, FileAttribute<?>... attrs) throws IOException {
        /*
         * Some Code
         */
        if (options.createNew() && openCryptoFiles.get(ciphertextFilePath).isPresent()) {
            throw new FileAlreadyExistsException(cleartextFilePath.toString());
        } else {
            /* More Code */ 

            FileChannel ch = openCryptoFiles.getOrCreate(ciphertextFilePath).newFileChannel(options);
            if (options.writable()) {
                ciphertextPath.persistLongFileName(); //always call the function
                stats.incrementAccessesWritten();
            }
            /* final statements */
            return ch;
        }
    }

[overheadhunter]

Agreed! Performance impact should be negligible and shortening occurs rarely.