syncthing/lib/scanner/walk.go

737 lines
22 KiB
Go
Raw Permalink Normal View History

2014-11-16 21:13:20 +01:00
// Copyright (C) 2014 The Syncthing Authors.
2014-09-29 21:43:32 +02:00
//
2015-03-07 21:36:35 +01: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 22:50:14 +02:00
package scanner
import (
"context"
"errors"
"fmt"
"path/filepath"
"strings"
2015-08-27 00:49:06 +02:00
"sync/atomic"
"time"
"unicode/utf8"
2014-08-16 18:33:01 +02:00
metrics "github.com/rcrowley/go-metrics"
"github.com/syncthing/syncthing/lib/build"
2015-08-27 00:49:06 +02:00
"github.com/syncthing/syncthing/lib/events"
"github.com/syncthing/syncthing/lib/fs"
"github.com/syncthing/syncthing/lib/ignore"
"github.com/syncthing/syncthing/lib/osutil"
2015-09-22 19:38:46 +02:00
"github.com/syncthing/syncthing/lib/protocol"
"golang.org/x/text/unicode/norm"
)
type Config struct {
2015-08-27 00:49:06 +02:00
// Folder for which the walker has been created
Folder string
// Limit walking to these paths within Dir, or no limit if Sub is empty
Subs []string
// If Matcher is not nil, it is used to identify files to ignore which were specified by the user.
Matcher *ignore.Matcher
// Number of hours to keep temporary files for
TempLifetime time.Duration
// If CurrentFiler is not nil, it is queried for the current file before rescanning.
CurrentFiler CurrentFiler
// The Filesystem provides an abstraction on top of the actual filesystem.
Filesystem fs.Filesystem
2014-05-23 14:31:16 +02:00
// If IgnorePerms is true, changes to permission bits will not be
// detected.
2014-05-23 14:31:16 +02:00
IgnorePerms bool
// When AutoNormalize is set, file names that are in UTF8 but incorrect
// normalization form will be corrected.
AutoNormalize bool
// Number of routines to use for hashing
Hashers int
2015-03-25 22:37:35 +01:00
// Our vector clock id
ShortID protocol.ShortID
2015-08-27 00:49:06 +02:00
// Optional progress tick interval which defines how often FolderScanProgress
// events are emitted. Negative number means disabled.
ProgressTickIntervalS int
// Local flags to set on scanned files
LocalFlags uint32
// Modification time is to be considered unchanged if the difference is lower.
ModTimeWindow time.Duration
// Event logger to which the scan progress events are sent
EventLogger events.Logger
// If ScanOwnership is true, we pick up ownership information on files while scanning.
ScanOwnership bool
// If ScanXattrs is true, we pick up extended attributes on files while scanning.
ScanXattrs bool
// Filter for extended attributes
XattrFilter XattrFilter
}
type CurrentFiler interface {
// CurrentFile returns the file as seen at last scan.
CurrentFile(name string) (protocol.FileInfo, bool)
2014-03-16 08:14:55 +01:00
}
type XattrFilter interface {
Permit(string) bool
GetMaxSingleEntrySize() int
GetMaxTotalSize() int
}
type ScanResult struct {
File protocol.FileInfo
Err error
Path string // to be set in case Err != nil and File == nil
}
func Walk(ctx context.Context, cfg Config) chan ScanResult {
return newWalker(cfg).walk(ctx)
}
func WalkWithoutHashing(ctx context.Context, cfg Config) chan ScanResult {
return newWalker(cfg).walkWithoutHashing(ctx)
}
func newWalker(cfg Config) *walker {
w := &walker{cfg}
if w.CurrentFiler == nil {
w.CurrentFiler = noCurrentFiler{}
}
if w.Filesystem == nil {
panic("no filesystem specified")
}
if w.Matcher == nil {
w.Matcher = ignore.New(w.Filesystem)
}
registerFolderMetrics(w.Folder)
return w
}
var (
errUTF8Invalid = errors.New("item is not in UTF8 encoding")
errUTF8Normalization = errors.New("item is not in the correct UTF8 normalization form")
errUTF8Conflict = errors.New("item has UTF8 encoding conflict with another item")
)
type walker struct {
Config
}
// Walk returns the list of files found in the local folder by scanning the
// file system. Files are blockwise hashed.
func (w *walker) walk(ctx context.Context) chan ScanResult {
l.Debugln(w, "Walk", w.Subs, w.Matcher)
toHashChan := make(chan protocol.FileInfo)
finishedChan := make(chan ScanResult)
// A routine which walks the filesystem tree, and sends files which have
// been modified to the counter routine.
go w.scan(ctx, toHashChan, finishedChan)
2015-08-27 00:49:06 +02:00
// We're not required to emit scan progress events, just kick off hashers,
// and feed inputs directly from the walker.
if w.ProgressTickIntervalS < 0 {
newParallelHasher(ctx, w.Folder, w.Filesystem, w.Hashers, finishedChan, toHashChan, nil, nil)
return finishedChan
2015-08-27 00:49:06 +02:00
}
// Defaults to every 2 seconds.
if w.ProgressTickIntervalS == 0 {
w.ProgressTickIntervalS = 2
}
// We need to emit progress events, hence we create a routine which buffers
// the list of files to be hashed, counts the total number of
// bytes to hash, and once no more files need to be hashed (chan gets closed),
// start a routine which periodically emits FolderScanProgress events,
// until a stop signal is sent by the parallel hasher.
// Parallel hasher is stopped by this routine when we close the channel over
// which it receives the files we ask it to hash.
go func() {
var filesToHash []protocol.FileInfo
2015-11-17 21:08:36 +01:00
var total int64 = 1
2015-08-27 00:49:06 +02:00
for file := range toHashChan {
filesToHash = append(filesToHash, file)
total += file.Size
2015-08-27 00:49:06 +02:00
}
if len(filesToHash) == 0 {
close(finishedChan)
return
}
realToHashChan := make(chan protocol.FileInfo)
2015-08-27 00:49:06 +02:00
done := make(chan struct{})
progress := newByteCounter()
newParallelHasher(ctx, w.Folder, w.Filesystem, w.Hashers, finishedChan, realToHashChan, progress, done)
2015-08-27 00:49:06 +02:00
// A routine which actually emits the FolderScanProgress events
// every w.ProgressTicker ticks, until the hasher routines terminate.
go func() {
defer progress.Close()
emitProgressEvent := func() {
current := progress.Total()
rate := progress.Rate()
l.Debugf("%v: Walk %s %s current progress %d/%d at %.01f MiB/s (%d%%)", w, w.Folder, w.Subs, current, total, rate/1024/1024, current*100/total)
w.EventLogger.Log(events.FolderScanProgress, map[string]interface{}{
"folder": w.Folder,
"current": current,
"total": total,
"rate": rate, // bytes per second
})
}
ticker := time.NewTicker(time.Duration(w.ProgressTickIntervalS) * time.Second)
defer ticker.Stop()
2015-08-27 00:49:06 +02:00
for {
select {
case <-done:
emitProgressEvent()
l.Debugln(w, "Walk progress done", w.Folder, w.Subs, w.Matcher)
2015-08-27 00:49:06 +02:00
return
case <-ticker.C:
emitProgressEvent()
case <-ctx.Done():
2015-11-13 15:00:32 +01:00
return
2015-08-27 00:49:06 +02:00
}
}
}()
2015-11-13 15:00:32 +01:00
loop:
2015-08-27 00:49:06 +02:00
for _, file := range filesToHash {
l.Debugln(w, "real to hash:", file.Name)
2015-11-13 15:00:32 +01:00
select {
case realToHashChan <- file:
case <-ctx.Done():
2015-11-13 15:00:32 +01:00
break loop
}
2015-08-27 00:49:06 +02:00
}
close(realToHashChan)
}()
return finishedChan
}
func (w *walker) walkWithoutHashing(ctx context.Context) chan ScanResult {
l.Debugln(w, "Walk without hashing", w.Subs, w.Matcher)
toHashChan := make(chan protocol.FileInfo)
finishedChan := make(chan ScanResult)
// A routine which walks the filesystem tree, and sends files which have
// been modified to the counter routine.
go w.scan(ctx, toHashChan, finishedChan)
go func() {
for file := range toHashChan {
finishedChan <- ScanResult{File: file}
}
close(finishedChan)
}()
return finishedChan
}
func (w *walker) scan(ctx context.Context, toHashChan chan<- protocol.FileInfo, finishedChan chan<- ScanResult) {
hashFiles := w.walkAndHashFiles(ctx, toHashChan, finishedChan)
if len(w.Subs) == 0 {
w.Filesystem.Walk(".", hashFiles)
} else {
for _, sub := range w.Subs {
if err := osutil.TraversesSymlink(w.Filesystem, filepath.Dir(sub)); err != nil {
l.Debugf("%v: Skip walking %v as it is below a symlink", w, sub)
continue
}
w.Filesystem.Walk(sub, hashFiles)
}
}
close(toHashChan)
}
func (w *walker) walkAndHashFiles(ctx context.Context, toHashChan chan<- protocol.FileInfo, finishedChan chan<- ScanResult) fs.WalkFunc {
now := time.Now()
ignoredParent := ""
return func(path string, info fs.FileInfo, err error) error {
select {
case <-ctx.Done():
return ctx.Err()
default:
}
metricScannedItems.WithLabelValues(w.Folder).Inc()
// Return value used when we are returning early and don't want to
// process the item. For directories, this means do-not-descend.
var skip error // nil
// info nil when error is not nil
if info != nil && info.IsDir() {
skip = fs.SkipDir
}
if !utf8.ValidString(path) {
handleError(ctx, "scan", path, errUTF8Invalid, finishedChan)
return skip
}
if fs.IsTemporary(path) {
l.Debugln(w, "temporary:", path, "err:", err)
if err == nil && info.IsRegular() && info.ModTime().Add(w.TempLifetime).Before(now) {
2019-02-02 12:16:27 +01:00
w.Filesystem.Remove(path)
l.Debugln(w, "removing temporary:", path, info.ModTime())
}
return nil
}
if fs.IsInternal(path) {
l.Debugln(w, "ignored (internal):", path)
return skip
}
lib/ignore: Optimise ignoring directories for filesystem watcher (fixes #9339) (#9340) This improves the ignore handling so that directories can be fully ignored (skipped in the watcher) in more cases. Specifically, where the previous rule was that any complex `!`-pattern would disable skipping directories, the new rule is that only matches on patterns *after* such a `!`-pattern disable skipping. That is, the following now does the intuitive thing: ``` /foo /bar !whatever * ``` - `/foo/**` and `/bar/**` are completely skipped, since there is no chance anything underneath them could ever be not-ignored - `!whatever` toggles the "can't skip directories any more" flag - Anything that matches `*` can't skip directories, because it's possible we can have `whatever` match something deeper. To enable this, some refactoring was necessary: - The "can skip dirs" flag is now a property of the match result, not of the pattern set as a whole. - That meant returning a boolean is not good enough, we need to actually return the entire `Result` (or, like, two booleans but that seemed uglier and more annoying to use) - `ShouldIgnore(string) boolean` went away with `Match(string).IsIgnored()` being the obvious replacement (API simplification!) - The watcher then needed to import the `ignore` package (for the `Result` type), but `fs` imports the watcher and `ignore` imports `fs`. That's a cycle, so I broke out `Result` into a package of its own so that it can be safely imported everywhere in things like `type Matcher interface { Match(string) result.Result }`. There's a fair amount of stuttering in `result.Result` and maybe we should go with something like `ignoreresult.R` or so, leaving this open for discussion. Tests refactored to suit, I think this change is in fact quite well covered by the existing ones... Also some noise because a few of the changed files were quite old and got the `gofumpt` treatment by my editor. Sorry not sorry. --------- Co-authored-by: Simon Frei <freisim93@gmail.com>
2024-01-15 11:13:22 +01:00
if m := w.Matcher.Match(path); m.IsIgnored() {
l.Debugln(w, "ignored (patterns):", path)
// Only descend if matcher says so and the current file is not a symlink.
lib/ignore: Optimise ignoring directories for filesystem watcher (fixes #9339) (#9340) This improves the ignore handling so that directories can be fully ignored (skipped in the watcher) in more cases. Specifically, where the previous rule was that any complex `!`-pattern would disable skipping directories, the new rule is that only matches on patterns *after* such a `!`-pattern disable skipping. That is, the following now does the intuitive thing: ``` /foo /bar !whatever * ``` - `/foo/**` and `/bar/**` are completely skipped, since there is no chance anything underneath them could ever be not-ignored - `!whatever` toggles the "can't skip directories any more" flag - Anything that matches `*` can't skip directories, because it's possible we can have `whatever` match something deeper. To enable this, some refactoring was necessary: - The "can skip dirs" flag is now a property of the match result, not of the pattern set as a whole. - That meant returning a boolean is not good enough, we need to actually return the entire `Result` (or, like, two booleans but that seemed uglier and more annoying to use) - `ShouldIgnore(string) boolean` went away with `Match(string).IsIgnored()` being the obvious replacement (API simplification!) - The watcher then needed to import the `ignore` package (for the `Result` type), but `fs` imports the watcher and `ignore` imports `fs`. That's a cycle, so I broke out `Result` into a package of its own so that it can be safely imported everywhere in things like `type Matcher interface { Match(string) result.Result }`. There's a fair amount of stuttering in `result.Result` and maybe we should go with something like `ignoreresult.R` or so, leaving this open for discussion. Tests refactored to suit, I think this change is in fact quite well covered by the existing ones... Also some noise because a few of the changed files were quite old and got the `gofumpt` treatment by my editor. Sorry not sorry. --------- Co-authored-by: Simon Frei <freisim93@gmail.com>
2024-01-15 11:13:22 +01:00
if err != nil || m.CanSkipDir() || info.IsSymlink() {
return skip
}
// If the parent wasn't ignored already, set this path as the "highest" ignored parent
if info.IsDir() && (ignoredParent == "" || !fs.IsParent(path, ignoredParent)) {
ignoredParent = path
}
return nil
}
if err != nil {
// No need reporting errors for files that don't exist (e.g. scan
// due to filesystem watcher)
if !fs.IsNotExist(err) {
handleError(ctx, "scan", path, err, finishedChan)
}
return skip
}
if path == "." {
return nil
}
if ignoredParent == "" {
// parent isn't ignored, nothing special
return w.handleItem(ctx, path, info, toHashChan, finishedChan, skip)
}
// Part of current path below the ignored (potential) parent
rel := strings.TrimPrefix(path, ignoredParent+string(fs.PathSeparator))
// ignored path isn't actually a parent of the current path
if rel == path {
ignoredParent = ""
return w.handleItem(ctx, path, info, toHashChan, finishedChan, skip)
}
// The previously ignored parent directories of the current, not
// ignored path need to be handled as well.
// Prepend an empty string to handle ignoredParent without anything
// appended in the first iteration.
for _, name := range append([]string{""}, fs.PathComponents(rel)...) {
ignoredParent = filepath.Join(ignoredParent, name)
info, err = w.Filesystem.Lstat(ignoredParent)
// An error here would be weird as we've already gotten to this point, but act on it nonetheless
if err != nil {
handleError(ctx, "scan", ignoredParent, err, finishedChan)
return skip
}
if err = w.handleItem(ctx, ignoredParent, info, toHashChan, finishedChan, skip); err != nil {
return err
}
}
ignoredParent = ""
return nil
}
}
func (w *walker) handleItem(ctx context.Context, path string, info fs.FileInfo, toHashChan chan<- protocol.FileInfo, finishedChan chan<- ScanResult, skip error) error {
oldPath := path
path, err := w.normalizePath(path, info)
if err != nil {
handleError(ctx, "normalizing path", oldPath, err, finishedChan)
return skip
}
switch {
case info.IsSymlink():
if err := w.walkSymlink(ctx, path, info, finishedChan); err != nil {
return err
}
if info.IsDir() {
// under no circumstances shall we descend into a symlink
return fs.SkipDir
}
return nil
case info.IsDir():
err = w.walkDir(ctx, path, info, finishedChan)
case info.IsRegular():
err = w.walkRegular(ctx, path, info, toHashChan)
}
return err
}
func (w *walker) walkRegular(ctx context.Context, relPath string, info fs.FileInfo, toHashChan chan<- protocol.FileInfo) error {
curFile, hasCurFile := w.CurrentFiler.CurrentFile(relPath)
blockSize := protocol.BlockSize(info.Size())
if hasCurFile {
// Check if we should retain current block size.
curBlockSize := curFile.BlockSize()
if blockSize > curBlockSize && blockSize/curBlockSize <= 2 {
// New block size is larger, but not more than twice larger.
// Retain.
blockSize = curBlockSize
} else if curBlockSize > blockSize && curBlockSize/blockSize <= 2 {
// Old block size is larger, but not more than twice larger.
// Retain.
blockSize = curBlockSize
}
}
f, err := CreateFileInfo(info, relPath, w.Filesystem, w.ScanOwnership, w.ScanXattrs, w.XattrFilter)
if err != nil {
return err
}
f = w.updateFileInfo(f, curFile)
f.NoPermissions = w.IgnorePerms
f.RawBlockSize = blockSize
l.Debugln(w, "checking:", f)
if hasCurFile {
if curFile.IsEquivalentOptional(f, protocol.FileInfoComparison{
ModTimeWindow: w.ModTimeWindow,
IgnorePerms: w.IgnorePerms,
IgnoreBlocks: true,
IgnoreFlags: w.LocalFlags,
IgnoreOwnership: !w.ScanOwnership,
IgnoreXattrs: !w.ScanXattrs,
}) {
l.Debugln(w, "unchanged:", curFile)
return nil
}
lib/scanner: Prevent sync-conflict for receive-only local modifications (#9323) ### Purpose This PR changes behaviour of syncthing related to `receive-only` folders, which I believe to be a bug since I wouldn't expect the current behaviour. With the current syncthing codebase, a file of a `receive-only` folder that is only modified locally can cause the creation of a `.sync-conflict` file. ### Testing Consider this szenario: Setup two paired clients that sync a folder with a given file (e.g. `Test.txt`). One of the clients configures the folder to be `receive-only`. Now, change the contents of the file for the receive-only client **_twice_**. With the current syncthing codebase, this leads to the creation of a `.sync-conflict` file that contains the modified contents, while the regular `Test.txt` file is reset to the cluster's provided contents. This is due to a `protocol.FileInfo#ShouldConflict` check, that is succeeding on the locally modified file. This PR changes this behaviour to not reset the file and not cause the creation of a `.sync-conflict`. Instead, the second content update is treated the same as the first content update. This PR also contains a test that fails on the current codebase and succeeds with the changes introduced in this PR. ### Screenshots This is not a GUI change ### Documentation This is not a user visible change. ## Authorship Your name and email will be added automatically to the AUTHORS file based on the commit metadata. #### Thanks to all the syncthing folks for this awesome piece of software!
2024-01-08 10:29:20 +01:00
if curFile.ShouldConflict() && !f.ShouldConflict() {
// The old file was invalid for whatever reason and probably not
// up to date with what was out there in the cluster. Drop all
// others from the version vector to indicate that we haven't
// taken their version into account, and possibly cause a
lib/scanner: Prevent sync-conflict for receive-only local modifications (#9323) ### Purpose This PR changes behaviour of syncthing related to `receive-only` folders, which I believe to be a bug since I wouldn't expect the current behaviour. With the current syncthing codebase, a file of a `receive-only` folder that is only modified locally can cause the creation of a `.sync-conflict` file. ### Testing Consider this szenario: Setup two paired clients that sync a folder with a given file (e.g. `Test.txt`). One of the clients configures the folder to be `receive-only`. Now, change the contents of the file for the receive-only client **_twice_**. With the current syncthing codebase, this leads to the creation of a `.sync-conflict` file that contains the modified contents, while the regular `Test.txt` file is reset to the cluster's provided contents. This is due to a `protocol.FileInfo#ShouldConflict` check, that is succeeding on the locally modified file. This PR changes this behaviour to not reset the file and not cause the creation of a `.sync-conflict`. Instead, the second content update is treated the same as the first content update. This PR also contains a test that fails on the current codebase and succeeds with the changes introduced in this PR. ### Screenshots This is not a GUI change ### Documentation This is not a user visible change. ## Authorship Your name and email will be added automatically to the AUTHORS file based on the commit metadata. #### Thanks to all the syncthing folks for this awesome piece of software!
2024-01-08 10:29:20 +01:00
// conflict. However, only do this if the new file is not also
// invalid. This would indicate that the new file is not part
// of the cluster, but e.g. a local change.
f.Version = f.Version.DropOthers(w.ShortID)
}
l.Debugln(w, "rescan:", curFile)
}
l.Debugln(w, "to hash:", relPath, f)
2015-11-20 10:32:16 +01:00
select {
case toHashChan <- f:
case <-ctx.Done():
return ctx.Err()
2015-11-20 10:32:16 +01:00
}
return nil
}
func (w *walker) walkDir(ctx context.Context, relPath string, info fs.FileInfo, finishedChan chan<- ScanResult) error {
curFile, hasCurFile := w.CurrentFiler.CurrentFile(relPath)
f, err := CreateFileInfo(info, relPath, w.Filesystem, w.ScanOwnership, w.ScanXattrs, w.XattrFilter)
if err != nil {
return err
}
f = w.updateFileInfo(f, curFile)
f.NoPermissions = w.IgnorePerms
l.Debugln(w, "checking:", f)
if hasCurFile {
if curFile.IsEquivalentOptional(f, protocol.FileInfoComparison{
ModTimeWindow: w.ModTimeWindow,
IgnorePerms: w.IgnorePerms,
IgnoreBlocks: true,
IgnoreFlags: w.LocalFlags,
IgnoreOwnership: !w.ScanOwnership,
IgnoreXattrs: !w.ScanXattrs,
}) {
l.Debugln(w, "unchanged:", curFile)
return nil
}
lib/scanner: Prevent sync-conflict for receive-only local modifications (#9323) ### Purpose This PR changes behaviour of syncthing related to `receive-only` folders, which I believe to be a bug since I wouldn't expect the current behaviour. With the current syncthing codebase, a file of a `receive-only` folder that is only modified locally can cause the creation of a `.sync-conflict` file. ### Testing Consider this szenario: Setup two paired clients that sync a folder with a given file (e.g. `Test.txt`). One of the clients configures the folder to be `receive-only`. Now, change the contents of the file for the receive-only client **_twice_**. With the current syncthing codebase, this leads to the creation of a `.sync-conflict` file that contains the modified contents, while the regular `Test.txt` file is reset to the cluster's provided contents. This is due to a `protocol.FileInfo#ShouldConflict` check, that is succeeding on the locally modified file. This PR changes this behaviour to not reset the file and not cause the creation of a `.sync-conflict`. Instead, the second content update is treated the same as the first content update. This PR also contains a test that fails on the current codebase and succeeds with the changes introduced in this PR. ### Screenshots This is not a GUI change ### Documentation This is not a user visible change. ## Authorship Your name and email will be added automatically to the AUTHORS file based on the commit metadata. #### Thanks to all the syncthing folks for this awesome piece of software!
2024-01-08 10:29:20 +01:00
if curFile.ShouldConflict() && !f.ShouldConflict() {
// The old file was invalid for whatever reason and probably not
// up to date with what was out there in the cluster. Drop all
// others from the version vector to indicate that we haven't
// taken their version into account, and possibly cause a
lib/scanner: Prevent sync-conflict for receive-only local modifications (#9323) ### Purpose This PR changes behaviour of syncthing related to `receive-only` folders, which I believe to be a bug since I wouldn't expect the current behaviour. With the current syncthing codebase, a file of a `receive-only` folder that is only modified locally can cause the creation of a `.sync-conflict` file. ### Testing Consider this szenario: Setup two paired clients that sync a folder with a given file (e.g. `Test.txt`). One of the clients configures the folder to be `receive-only`. Now, change the contents of the file for the receive-only client **_twice_**. With the current syncthing codebase, this leads to the creation of a `.sync-conflict` file that contains the modified contents, while the regular `Test.txt` file is reset to the cluster's provided contents. This is due to a `protocol.FileInfo#ShouldConflict` check, that is succeeding on the locally modified file. This PR changes this behaviour to not reset the file and not cause the creation of a `.sync-conflict`. Instead, the second content update is treated the same as the first content update. This PR also contains a test that fails on the current codebase and succeeds with the changes introduced in this PR. ### Screenshots This is not a GUI change ### Documentation This is not a user visible change. ## Authorship Your name and email will be added automatically to the AUTHORS file based on the commit metadata. #### Thanks to all the syncthing folks for this awesome piece of software!
2024-01-08 10:29:20 +01:00
// conflict. However, only do this if the new file is not also
// invalid. This would indicate that the new file is not part
// of the cluster, but e.g. a local change.
f.Version = f.Version.DropOthers(w.ShortID)
}
l.Debugln(w, "rescan:", curFile)
}
l.Debugln(w, "dir:", relPath, f)
2015-11-20 09:54:12 +01:00
select {
case finishedChan <- ScanResult{File: f}:
case <-ctx.Done():
return ctx.Err()
2015-11-20 09:54:12 +01:00
}
return nil
2015-11-20 09:54:12 +01:00
}
// walkSymlink returns nil or an error, if the error is of the nature that
// it should stop the entire walk.
func (w *walker) walkSymlink(ctx context.Context, relPath string, info fs.FileInfo, finishedChan chan<- ScanResult) error {
// Symlinks are not supported on Windows. We ignore instead of returning
// an error.
if build.IsWindows {
return nil
}
f, err := CreateFileInfo(info, relPath, w.Filesystem, w.ScanOwnership, w.ScanXattrs, w.XattrFilter)
2015-11-20 09:50:46 +01:00
if err != nil {
handleError(ctx, "reading link", relPath, err, finishedChan)
return nil
2015-11-20 09:50:46 +01:00
}
curFile, hasCurFile := w.CurrentFiler.CurrentFile(relPath)
f = w.updateFileInfo(f, curFile)
l.Debugln(w, "checking:", f)
2015-11-20 09:50:46 +01:00
if hasCurFile {
if curFile.IsEquivalentOptional(f, protocol.FileInfoComparison{
ModTimeWindow: w.ModTimeWindow,
IgnorePerms: w.IgnorePerms,
IgnoreBlocks: true,
IgnoreFlags: w.LocalFlags,
IgnoreOwnership: !w.ScanOwnership,
IgnoreXattrs: !w.ScanXattrs,
}) {
l.Debugln(w, "unchanged:", curFile, info.ModTime().Unix(), info.Mode()&fs.ModePerm)
return nil
}
lib/scanner: Prevent sync-conflict for receive-only local modifications (#9323) ### Purpose This PR changes behaviour of syncthing related to `receive-only` folders, which I believe to be a bug since I wouldn't expect the current behaviour. With the current syncthing codebase, a file of a `receive-only` folder that is only modified locally can cause the creation of a `.sync-conflict` file. ### Testing Consider this szenario: Setup two paired clients that sync a folder with a given file (e.g. `Test.txt`). One of the clients configures the folder to be `receive-only`. Now, change the contents of the file for the receive-only client **_twice_**. With the current syncthing codebase, this leads to the creation of a `.sync-conflict` file that contains the modified contents, while the regular `Test.txt` file is reset to the cluster's provided contents. This is due to a `protocol.FileInfo#ShouldConflict` check, that is succeeding on the locally modified file. This PR changes this behaviour to not reset the file and not cause the creation of a `.sync-conflict`. Instead, the second content update is treated the same as the first content update. This PR also contains a test that fails on the current codebase and succeeds with the changes introduced in this PR. ### Screenshots This is not a GUI change ### Documentation This is not a user visible change. ## Authorship Your name and email will be added automatically to the AUTHORS file based on the commit metadata. #### Thanks to all the syncthing folks for this awesome piece of software!
2024-01-08 10:29:20 +01:00
if curFile.ShouldConflict() && !f.ShouldConflict() {
// The old file was invalid for whatever reason and probably not
// up to date with what was out there in the cluster. Drop all
// others from the version vector to indicate that we haven't
// taken their version into account, and possibly cause a
lib/scanner: Prevent sync-conflict for receive-only local modifications (#9323) ### Purpose This PR changes behaviour of syncthing related to `receive-only` folders, which I believe to be a bug since I wouldn't expect the current behaviour. With the current syncthing codebase, a file of a `receive-only` folder that is only modified locally can cause the creation of a `.sync-conflict` file. ### Testing Consider this szenario: Setup two paired clients that sync a folder with a given file (e.g. `Test.txt`). One of the clients configures the folder to be `receive-only`. Now, change the contents of the file for the receive-only client **_twice_**. With the current syncthing codebase, this leads to the creation of a `.sync-conflict` file that contains the modified contents, while the regular `Test.txt` file is reset to the cluster's provided contents. This is due to a `protocol.FileInfo#ShouldConflict` check, that is succeeding on the locally modified file. This PR changes this behaviour to not reset the file and not cause the creation of a `.sync-conflict`. Instead, the second content update is treated the same as the first content update. This PR also contains a test that fails on the current codebase and succeeds with the changes introduced in this PR. ### Screenshots This is not a GUI change ### Documentation This is not a user visible change. ## Authorship Your name and email will be added automatically to the AUTHORS file based on the commit metadata. #### Thanks to all the syncthing folks for this awesome piece of software!
2024-01-08 10:29:20 +01:00
// conflict. However, only do this if the new file is not also
// invalid. This would indicate that the new file is not part
// of the cluster, but e.g. a local change.
f.Version = f.Version.DropOthers(w.ShortID)
}
l.Debugln(w, "rescan:", curFile)
}
l.Debugln(w, "symlink:", relPath, f)
2015-11-20 09:50:46 +01:00
select {
case finishedChan <- ScanResult{File: f}:
case <-ctx.Done():
return ctx.Err()
2015-11-20 09:50:46 +01:00
}
return nil
2015-11-20 09:50:46 +01:00
}
// normalizePath returns the normalized relative path (possibly after fixing
// it on disk), or skip is true.
func (w *walker) normalizePath(path string, info fs.FileInfo) (normPath string, err error) {
if build.IsDarwin {
// Mac OS X file names should always be NFD normalized.
normPath = norm.NFD.String(path)
} else {
// Every other OS in the known universe uses NFC or just plain
// doesn't bother to define an encoding. In our case *we* do care,
// so we enforce NFC regardless.
normPath = norm.NFC.String(path)
}
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 19:11:09 +01:00
if path == normPath {
// The file name is already normalized: nothing to do
return path, nil
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 19:11:09 +01:00
}
if !w.AutoNormalize {
// We're not authorized to do anything about it, so complain and skip.
return "", errUTF8Normalization
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 19:11:09 +01:00
}
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 19:11:09 +01:00
// We will attempt to normalize it.
normInfo, err := w.Filesystem.Lstat(normPath)
if fs.IsNotExist(err) {
// Nothing exists with the normalized filename. Good.
if err = w.Filesystem.Rename(path, normPath); err != nil {
return "", err
}
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 19:11:09 +01:00
l.Infof(`Normalized UTF8 encoding of file name "%s".`, path)
return normPath, nil
}
if w.Filesystem.SameFile(info, normInfo) {
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 19:11:09 +01:00
// With some filesystems (ZFS), if there is an un-normalized path and you ask whether the normalized
// version exists, it responds with true. Therefore we need to check fs.SameFile as well.
// In this case, a call to Rename won't do anything, so we have to rename via a temp file.
// We don't want to use the standard syncthing prefix here, as that will result in the file being ignored
// and eventually deleted by Syncthing if the rename back fails.
tempPath := fs.TempNameWithPrefix(normPath, "")
if err = w.Filesystem.Rename(path, tempPath); err != nil {
return "", err
}
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 19:11:09 +01:00
if err = w.Filesystem.Rename(tempPath, normPath); err != nil {
// I don't ever expect this to happen, but if it does, we should probably tell our caller that the normalized
// path is the temp path: that way at least the user's data still gets synced.
l.Warnf(`Error renaming "%s" to "%s" while normalizating UTF8 encoding: %v. You will want to rename this file back manually`, tempPath, normPath, err)
return tempPath, nil
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 19:11:09 +01:00
}
return normPath, nil
}
// There is something already in the way at the normalized
// file name.
return "", errUTF8Conflict
}
// updateFileInfo updates walker specific members of protocol.FileInfo that
// do not depend on type, and things that should be preserved from the
// previous version of the FileInfo.
func (w *walker) updateFileInfo(dst, src protocol.FileInfo) protocol.FileInfo {
if dst.Type == protocol.FileInfoTypeFile && build.IsWindows {
// If we have an existing index entry, copy the executable bits
// from there.
dst.Permissions |= (src.Permissions & 0o111)
}
dst.Version = src.Version.Update(w.ShortID)
dst.ModifiedBy = w.ShortID
dst.LocalFlags = w.LocalFlags
// Copy OS data from src to dst, unless it was already set on dst.
dst.Platform.MergeWith(&src.Platform)
return dst
}
func handleError(ctx context.Context, context, path string, err error, finishedChan chan<- ScanResult) {
select {
case finishedChan <- ScanResult{
Err: fmt.Errorf("%s: %w", context, err),
Path: path,
}:
case <-ctx.Done():
}
}
func (w *walker) String() string {
return fmt.Sprintf("walker/%s@%p", w.Folder, w)
}
2015-11-17 21:08:36 +01:00
// A byteCounter gets bytes added to it via Update() and then provides the
// Total() and one minute moving average Rate() in bytes per second.
type byteCounter struct {
total atomic.Int64
2015-11-17 21:08:36 +01:00
metrics.EWMA
stop chan struct{}
}
func newByteCounter() *byteCounter {
c := &byteCounter{
EWMA: metrics.NewEWMA1(), // a one minute exponentially weighted moving average
stop: make(chan struct{}),
}
go c.ticker()
return c
}
func (c *byteCounter) ticker() {
// The metrics.EWMA expects clock ticks every five seconds in order to
// decay the average properly.
t := time.NewTicker(5 * time.Second)
for {
select {
case <-t.C:
c.Tick()
case <-c.stop:
t.Stop()
return
}
}
}
func (c *byteCounter) Update(bytes int64) {
c.total.Add(bytes)
2015-11-17 21:08:36 +01:00
c.EWMA.Update(bytes)
}
func (c *byteCounter) Total() int64 { return c.total.Load() }
2015-11-17 21:08:36 +01:00
func (c *byteCounter) Close() {
close(c.stop)
}
// A no-op CurrentFiler
type noCurrentFiler struct{}
func (noCurrentFiler) CurrentFile(_ string) (protocol.FileInfo, bool) {
return protocol.FileInfo{}, false
}
func CreateFileInfo(fi fs.FileInfo, name string, filesystem fs.Filesystem, scanOwnership bool, scanXattrs bool, xattrFilter XattrFilter) (protocol.FileInfo, error) {
f := protocol.FileInfo{Name: name}
if scanOwnership || scanXattrs {
if plat, err := filesystem.PlatformData(name, scanOwnership, scanXattrs, xattrFilter); err == nil {
f.Platform = plat
} else {
return protocol.FileInfo{}, fmt.Errorf("reading platform data: %w", err)
}
}
if ct := fi.InodeChangeTime(); !ct.IsZero() {
f.InodeChangeNs = ct.UnixNano()
} else {
f.InodeChangeNs = 0
}
if fi.IsSymlink() {
f.Type = protocol.FileInfoTypeSymlink
target, err := filesystem.ReadSymlink(name)
if err != nil {
return protocol.FileInfo{}, err
}
f.SymlinkTarget = target
f.NoPermissions = true // Symlinks don't have permissions of their own
return f, nil
}
f.Permissions = uint32(fi.Mode() & fs.ModePerm)
f.ModifiedS = fi.ModTime().Unix()
f.ModifiedNs = fi.ModTime().Nanosecond()
if fi.IsDir() {
f.Type = protocol.FileInfoTypeDirectory
return f, nil
}
f.Size = fi.Size()
f.Type = protocol.FileInfoTypeFile
return f, nil
}