syncthing/lib/fs/tempname.go

60 lines
1.5 KiB
Go
Raw Normal View History

// Copyright (C) 2015 The Syncthing Authors.
2014-09-29 19:43:32 +00:00
//
2015-03-07 20:36:35 +00:00
// This Source Code Form is subject to the terms of the Mozilla Public
// License, v. 2.0. If a copy of the MPL was not distributed with this file,
// You can obtain one at https://mozilla.org/MPL/2.0/.
2014-06-01 20:50:14 +00:00
package fs
import (
lib/sha256: Remove it (#9643) ### Purpose Remove the `lib/sha256` package, because it's no longer necessary. Go's standard library now has the same performance and is on par with `sha256-simd` since [Since Go 1.21](https://github.com/golang/go/commit/1a64574f42b95594cf9c8a12e9ca13d75585429c). Therefore using `sha256-simd` has no benefits anymore. ARM already has optimized sha256 assembly code since https://github.com/golang/go/commit/7b8a7f8272fd1941a199af1adb334bd9996e8909, `sha256-simd` published their results before that optimized assembly was implemented, https://github.com/minio/sha256-simd/commit/f941fedda826b68a196de2e0a9183e273ec0cb91. The assembly looks very similar and the benchmarks in the Go commit match that of `sha256-simd`. This patch removes all of the related code of `lib/sha256` and makes `crypto/sha256` the 'default'. Benchmark of `sha256-simd` and `crypto/sha256`: <details> ``` cpu: AMD Ryzen 5 3600X 6-Core Processor │ simd.txt │ go.txt │ │ sec/op │ sec/op vs base │ Hash/8Bytes-12 63.25n ± 1% 73.38n ± 1% +16.02% (p=0.002 n=6) Hash/64Bytes-12 98.73n ± 1% 105.30n ± 1% +6.65% (p=0.002 n=6) Hash/1K-12 567.2n ± 1% 572.8n ± 1% +0.99% (p=0.002 n=6) Hash/8K-12 4.062µ ± 1% 4.062µ ± 1% ~ (p=0.396 n=6) Hash/1M-12 512.1µ ± 0% 510.6µ ± 1% ~ (p=0.485 n=6) Hash/5M-12 2.556m ± 1% 2.564m ± 0% ~ (p=0.093 n=6) Hash/10M-12 5.112m ± 0% 5.127m ± 0% ~ (p=0.093 n=6) geomean 13.82µ 14.27µ +3.28% │ simd.txt │ go.txt │ │ B/s │ B/s vs base │ Hash/8Bytes-12 120.6Mi ± 1% 104.0Mi ± 1% -13.81% (p=0.002 n=6) Hash/64Bytes-12 618.2Mi ± 1% 579.8Mi ± 1% -6.22% (p=0.002 n=6) Hash/1K-12 1.682Gi ± 1% 1.665Gi ± 1% -0.98% (p=0.002 n=6) Hash/8K-12 1.878Gi ± 1% 1.878Gi ± 1% ~ (p=0.310 n=6) Hash/1M-12 1.907Gi ± 0% 1.913Gi ± 1% ~ (p=0.485 n=6) Hash/5M-12 1.911Gi ± 1% 1.904Gi ± 0% ~ (p=0.093 n=6) Hash/10M-12 1.910Gi ± 0% 1.905Gi ± 0% ~ (p=0.093 n=6) geomean 1.066Gi 1.032Gi -3.18% ``` </details> ### Testing Compiled and tested on Linux. ### Documentation https://github.com/syncthing/docs/pull/874
2024-08-10 11:58:20 +00:00
"crypto/sha256"
"fmt"
"path/filepath"
"strings"
"github.com/syncthing/syncthing/lib/build"
)
const (
WindowsTempPrefix = "~syncthing~"
UnixTempPrefix = ".syncthing."
)
func tempPrefix() string {
if build.IsWindows {
return WindowsTempPrefix
} else {
return UnixTempPrefix
}
}
// Real filesystems usually handle 255 bytes. encfs has varying and
// confusing file name limits. We take a safe way out and switch to hashing
// quite early.
const maxFilenameLength = 160 - len(UnixTempPrefix) - len(".tmp")
// IsTemporary is true if the file name has the temporary prefix. Regardless
// of the normally used prefix, the standard Windows and Unix temp prefixes
// are always recognized as temp files.
func IsTemporary(name string) bool {
name = filepath.Base(name)
return strings.HasPrefix(name, WindowsTempPrefix) ||
strings.HasPrefix(name, UnixTempPrefix)
}
lib/scanner: Fix UTF-8 normalization on ZFS (fixes #4649) It turns out that ZFS doesn't do any normalization when storing files, but does do normalization "as part of any comparison process". In practice, this seems to mean that if you LStat a normalized filename, ZFS will return the FileInfo for the un-normalized version of that filename. This meant that our test to see whether a separate file with a normalized version of the filename already exists was failing, as we were detecting the same file. The fix is to use os.SameFile, to see whether we're getting the same FileInfo from the normalized and un-normalized versions of the same filename. One complication is that ZFS also seems to apply its magic to os.Rename, meaning that we can't use it to rename an un-normalized file to its normalized filename. Instead we have to move via a temporary object. If the move to the temporary object fails, that's OK, we can skip it and move on. If the move from the temporary object fails however, I'm not sure of the best approach: the current one is to leave the temporary file name as-is, and get Syncthing to syncronize it, so at least we don't lose the file. I'm not sure if there are any implications of this however. As part of reworking normalizePath, I spotted that it appeared to be returning the wrong thing: the doc and the surrounding code expecting it to return the normalized filename, but it was returning the un-normalized one. I fixed this, but it seems suspicious that, if the previous behaviour was incorrect, noone ever ran afoul of it. Maybe all filesystems will do some searching and give you a normalized filename if you request an unnormalized one. As part of this, I found that TestNormalization was broken: it was passing, when in fact one of the files it should have verified was present was missing. Maybe this was related to the above issue with normalizePath's return value, I'm not sure. Fixed en route. Kindly tested by @khinsen on the forum, and it appears to work. GitHub-Pull-Request: https://github.com/syncthing/syncthing/pull/4646
2018-01-05 18:11:09 +00:00
func TempNameWithPrefix(name, prefix string) string {
tdir := filepath.Dir(name)
tbase := filepath.Base(name)
var tname string
if len(tbase) > maxFilenameLength {
tname = fmt.Sprintf("%s%x.tmp", prefix, sha256.Sum256([]byte(tbase)))
} else {
tname = prefix + tbase + ".tmp"
}
return filepath.Join(tdir, tname)
}
lib/scanner: Fix UTF-8 normalization on ZFS (fixes #4649) It turns out that ZFS doesn't do any normalization when storing files, but does do normalization "as part of any comparison process". In practice, this seems to mean that if you LStat a normalized filename, ZFS will return the FileInfo for the un-normalized version of that filename. This meant that our test to see whether a separate file with a normalized version of the filename already exists was failing, as we were detecting the same file. The fix is to use os.SameFile, to see whether we're getting the same FileInfo from the normalized and un-normalized versions of the same filename. One complication is that ZFS also seems to apply its magic to os.Rename, meaning that we can't use it to rename an un-normalized file to its normalized filename. Instead we have to move via a temporary object. If the move to the temporary object fails, that's OK, we can skip it and move on. If the move from the temporary object fails however, I'm not sure of the best approach: the current one is to leave the temporary file name as-is, and get Syncthing to syncronize it, so at least we don't lose the file. I'm not sure if there are any implications of this however. As part of reworking normalizePath, I spotted that it appeared to be returning the wrong thing: the doc and the surrounding code expecting it to return the normalized filename, but it was returning the un-normalized one. I fixed this, but it seems suspicious that, if the previous behaviour was incorrect, noone ever ran afoul of it. Maybe all filesystems will do some searching and give you a normalized filename if you request an unnormalized one. As part of this, I found that TestNormalization was broken: it was passing, when in fact one of the files it should have verified was present was missing. Maybe this was related to the above issue with normalizePath's return value, I'm not sure. Fixed en route. Kindly tested by @khinsen on the forum, and it appears to work. GitHub-Pull-Request: https://github.com/syncthing/syncthing/pull/4646
2018-01-05 18:11:09 +00:00
func TempName(name string) string {
return TempNameWithPrefix(name, tempPrefix())
lib/scanner: Fix UTF-8 normalization on ZFS (fixes #4649) It turns out that ZFS doesn't do any normalization when storing files, but does do normalization "as part of any comparison process". In practice, this seems to mean that if you LStat a normalized filename, ZFS will return the FileInfo for the un-normalized version of that filename. This meant that our test to see whether a separate file with a normalized version of the filename already exists was failing, as we were detecting the same file. The fix is to use os.SameFile, to see whether we're getting the same FileInfo from the normalized and un-normalized versions of the same filename. One complication is that ZFS also seems to apply its magic to os.Rename, meaning that we can't use it to rename an un-normalized file to its normalized filename. Instead we have to move via a temporary object. If the move to the temporary object fails, that's OK, we can skip it and move on. If the move from the temporary object fails however, I'm not sure of the best approach: the current one is to leave the temporary file name as-is, and get Syncthing to syncronize it, so at least we don't lose the file. I'm not sure if there are any implications of this however. As part of reworking normalizePath, I spotted that it appeared to be returning the wrong thing: the doc and the surrounding code expecting it to return the normalized filename, but it was returning the un-normalized one. I fixed this, but it seems suspicious that, if the previous behaviour was incorrect, noone ever ran afoul of it. Maybe all filesystems will do some searching and give you a normalized filename if you request an unnormalized one. As part of this, I found that TestNormalization was broken: it was passing, when in fact one of the files it should have verified was present was missing. Maybe this was related to the above issue with normalizePath's return value, I'm not sure. Fixed en route. Kindly tested by @khinsen on the forum, and it appears to work. GitHub-Pull-Request: https://github.com/syncthing/syncthing/pull/4646
2018-01-05 18:11:09 +00:00
}