Fix handling of option core.supportsAtomicCreateNewFile

When core.supportsAtomicCreateNewFile was set to false and the
repository was located on a filesystem which doesn't support the file
attribute "unix:nlink" then FS_POSIX#createNewFile may report an error
even if everything was ok. Modify FS_POSIX#createNewFile to silently
ignore this situation. An example of such a filesystem is sshfs where
reading "unix:nlink" always returns 1 (instead of throwing a exception).

Bug: 537969
Change-Id: I6deda7672fa7945efa8706ea1cd652272604ff19
Also-by: Thomas Wolf <thomas.wolf@paranor.ch>
This commit is contained in:
Christian Halstrick 2018-08-17 17:46:09 +02:00 committed by Matthias Sohn
parent b7351facd5
commit 2faccd5b32
1 changed files with 10 additions and 4 deletions

View File

@ -371,22 +371,28 @@ public boolean createNewFile(File lock) throws IOException {
return true;
}
Path lockPath = lock.toPath();
Path link = Files.createLink(Paths.get(lock.getAbsolutePath() + ".lnk"), //$NON-NLS-1$
lockPath);
Path link = null;
try {
link = Files.createLink(
Paths.get(lock.getAbsolutePath() + ".lnk"), //$NON-NLS-1$
lockPath);
Integer nlink = (Integer) (Files.getAttribute(lockPath,
"unix:nlink")); //$NON-NLS-1$
if (nlink != 2) {
if (nlink > 2) {
LOG.warn("nlink of link to lock file {0} was not 2 but {1}", //$NON-NLS-1$
lock.getPath(), nlink);
return false;
} else if (nlink < 2) {
supportsUnixNLink = false;
}
return true;
} catch (UnsupportedOperationException | IllegalArgumentException e) {
supportsUnixNLink = false;
return true;
} finally {
Files.delete(link);
if (link != null) {
Files.delete(link);
}
}
}
}