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:
parent
b7351facd5
commit
2faccd5b32
|
@ -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);
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
Loading…
Reference in New Issue