2014-11-16 20:13:20 +00:00
|
|
|
// Copyright (C) 2014 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,
|
2017-02-09 06:52:18 +00:00
|
|
|
// You can obtain one at https://mozilla.org/MPL/2.0/.
|
2014-06-01 20:50:14 +00:00
|
|
|
|
2015-01-12 13:50:30 +00:00
|
|
|
// Package db provides a set type to track local/remote files with newness
|
2014-08-15 10:52:16 +00:00
|
|
|
// checks. We must do a certain amount of normalization in here. We will get
|
|
|
|
|
// fed paths with either native or wire-format separators and encodings
|
|
|
|
|
// depending on who calls us. We transform paths to wire-format (NFC and
|
|
|
|
|
// slashes) on the way to the database, and transform to native format
|
|
|
|
|
// (varying separator and encoding) on the way back out.
|
2015-01-12 13:50:30 +00:00
|
|
|
package db
|
2014-03-28 13:36:57 +00:00
|
|
|
|
|
|
|
|
import (
|
refactor: use modern Protobuf encoder (#9817)
At a high level, this is what I've done and why:
- I'm moving the protobuf generation for the `protocol`, `discovery` and
`db` packages to the modern alternatives, and using `buf` to generate
because it's nice and simple.
- After trying various approaches on how to integrate the new types with
the existing code, I opted for splitting off our own data model types
from the on-the-wire generated types. This means we can have a
`FileInfo` type with nicer ergonomics and lots of methods, while the
protobuf generated type stays clean and close to the wire protocol. It
does mean copying between the two when required, which certainly adds a
small amount of inefficiency. If we want to walk this back in the future
and use the raw generated type throughout, that's possible, this however
makes the refactor smaller (!) as it doesn't change everything about the
type for everyone at the same time.
- I have simply removed in cold blood a significant number of old
database migrations. These depended on previous generations of generated
messages of various kinds and were annoying to support in the new
fashion. The oldest supported database version now is the one from
Syncthing 1.9.0 from Sep 7, 2020.
- I changed config structs to be regular manually defined structs.
For the sake of discussion, some things I tried that turned out not to
work...
### Embedding / wrapping
Embedding the protobuf generated structs in our existing types as a data
container and keeping our methods and stuff:
```
package protocol
type FileInfo struct {
*generated.FileInfo
}
```
This generates a lot of problems because the internal shape of the
generated struct is quite different (different names, different types,
more pointers), because initializing it doesn't work like you'd expect
(i.e., you end up with an embedded nil pointer and a panic), and because
the types of child types don't get wrapped. That is, even if we also
have a similar wrapper around a `Vector`, that's not the type you get
when accessing `someFileInfo.Version`, you get the `*generated.Vector`
that doesn't have methods, etc.
### Aliasing
```
package protocol
type FileInfo = generated.FileInfo
```
Doesn't help because you can't attach methods to it, plus all the above.
### Generating the types into the target package like we do now and
attaching methods
This fails because of the different shape of the generated type (as in
the embedding case above) plus the generated struct already has a bunch
of methods that we can't necessarily override properly (like `String()`
and a bunch of getters).
### Methods to functions
I considered just moving all the methods we attach to functions in a
specific package, so that for example
```
package protocol
func (f FileInfo) Equal(other FileInfo) bool
```
would become
```
package fileinfos
func Equal(a, b *generated.FileInfo) bool
```
and this would mostly work, but becomes quite verbose and cumbersome,
and somewhat limits discoverability (you can't see what methods are
available on the type in auto completions, etc). In the end I did this
in some cases, like in the database layer where a lot of things like
`func (fv *FileVersion) IsEmpty() bool` becomes `func fvIsEmpty(fv
*generated.FileVersion)` because they were anyway just internal methods.
Fixes #8247
2024-12-01 15:50:17 +00:00
|
|
|
"bytes"
|
2020-08-01 15:32:36 +00:00
|
|
|
"fmt"
|
|
|
|
|
|
refactor: use modern Protobuf encoder (#9817)
At a high level, this is what I've done and why:
- I'm moving the protobuf generation for the `protocol`, `discovery` and
`db` packages to the modern alternatives, and using `buf` to generate
because it's nice and simple.
- After trying various approaches on how to integrate the new types with
the existing code, I opted for splitting off our own data model types
from the on-the-wire generated types. This means we can have a
`FileInfo` type with nicer ergonomics and lots of methods, while the
protobuf generated type stays clean and close to the wire protocol. It
does mean copying between the two when required, which certainly adds a
small amount of inefficiency. If we want to walk this back in the future
and use the raw generated type throughout, that's possible, this however
makes the refactor smaller (!) as it doesn't change everything about the
type for everyone at the same time.
- I have simply removed in cold blood a significant number of old
database migrations. These depended on previous generations of generated
messages of various kinds and were annoying to support in the new
fashion. The oldest supported database version now is the one from
Syncthing 1.9.0 from Sep 7, 2020.
- I changed config structs to be regular manually defined structs.
For the sake of discussion, some things I tried that turned out not to
work...
### Embedding / wrapping
Embedding the protobuf generated structs in our existing types as a data
container and keeping our methods and stuff:
```
package protocol
type FileInfo struct {
*generated.FileInfo
}
```
This generates a lot of problems because the internal shape of the
generated struct is quite different (different names, different types,
more pointers), because initializing it doesn't work like you'd expect
(i.e., you end up with an embedded nil pointer and a panic), and because
the types of child types don't get wrapped. That is, even if we also
have a similar wrapper around a `Vector`, that's not the type you get
when accessing `someFileInfo.Version`, you get the `*generated.Vector`
that doesn't have methods, etc.
### Aliasing
```
package protocol
type FileInfo = generated.FileInfo
```
Doesn't help because you can't attach methods to it, plus all the above.
### Generating the types into the target package like we do now and
attaching methods
This fails because of the different shape of the generated type (as in
the embedding case above) plus the generated struct already has a bunch
of methods that we can't necessarily override properly (like `String()`
and a bunch of getters).
### Methods to functions
I considered just moving all the methods we attach to functions in a
specific package, so that for example
```
package protocol
func (f FileInfo) Equal(other FileInfo) bool
```
would become
```
package fileinfos
func Equal(a, b *generated.FileInfo) bool
```
and this would mostly work, but becomes quite verbose and cumbersome,
and somewhat limits discoverability (you can't see what methods are
available on the type in auto completions, etc). In the end I did this
in some cases, like in the database layer where a lot of things like
`func (fv *FileVersion) IsEmpty() bool` becomes `func fvIsEmpty(fv
*generated.FileVersion)` because they were anyway just internal methods.
Fixes #8247
2024-12-01 15:50:17 +00:00
|
|
|
"github.com/syncthing/syncthing/internal/gen/dbproto"
|
2019-11-29 08:11:52 +00:00
|
|
|
"github.com/syncthing/syncthing/lib/db/backend"
|
2016-08-05 17:45:45 +00:00
|
|
|
"github.com/syncthing/syncthing/lib/fs"
|
2015-08-06 09:29:25 +00:00
|
|
|
"github.com/syncthing/syncthing/lib/osutil"
|
2015-09-22 17:38:46 +00:00
|
|
|
"github.com/syncthing/syncthing/lib/protocol"
|
2015-08-06 09:29:25 +00:00
|
|
|
"github.com/syncthing/syncthing/lib/sync"
|
2014-03-28 13:36:57 +00:00
|
|
|
)
|
|
|
|
|
|
2015-01-12 13:52:24 +00:00
|
|
|
type FileSet struct {
|
2019-01-23 09:22:33 +00:00
|
|
|
folder string
|
2019-12-02 07:18:04 +00:00
|
|
|
db *Lowlevel
|
2019-01-23 09:22:33 +00:00
|
|
|
meta *metadataTracker
|
2017-12-14 09:51:17 +00:00
|
|
|
|
|
|
|
|
updateMutex sync.Mutex // protects database updates and the corresponding metadata changes
|
2014-03-28 13:36:57 +00:00
|
|
|
}
|
|
|
|
|
|
2015-01-09 07:18:42 +00:00
|
|
|
// The Iterator is called with either a protocol.FileInfo or a
|
2016-07-04 10:40:29 +00:00
|
|
|
// FileInfoTruncated (depending on the method) and returns true to
|
2015-01-09 07:18:42 +00:00
|
|
|
// continue iteration, false to stop.
|
refactor: use modern Protobuf encoder (#9817)
At a high level, this is what I've done and why:
- I'm moving the protobuf generation for the `protocol`, `discovery` and
`db` packages to the modern alternatives, and using `buf` to generate
because it's nice and simple.
- After trying various approaches on how to integrate the new types with
the existing code, I opted for splitting off our own data model types
from the on-the-wire generated types. This means we can have a
`FileInfo` type with nicer ergonomics and lots of methods, while the
protobuf generated type stays clean and close to the wire protocol. It
does mean copying between the two when required, which certainly adds a
small amount of inefficiency. If we want to walk this back in the future
and use the raw generated type throughout, that's possible, this however
makes the refactor smaller (!) as it doesn't change everything about the
type for everyone at the same time.
- I have simply removed in cold blood a significant number of old
database migrations. These depended on previous generations of generated
messages of various kinds and were annoying to support in the new
fashion. The oldest supported database version now is the one from
Syncthing 1.9.0 from Sep 7, 2020.
- I changed config structs to be regular manually defined structs.
For the sake of discussion, some things I tried that turned out not to
work...
### Embedding / wrapping
Embedding the protobuf generated structs in our existing types as a data
container and keeping our methods and stuff:
```
package protocol
type FileInfo struct {
*generated.FileInfo
}
```
This generates a lot of problems because the internal shape of the
generated struct is quite different (different names, different types,
more pointers), because initializing it doesn't work like you'd expect
(i.e., you end up with an embedded nil pointer and a panic), and because
the types of child types don't get wrapped. That is, even if we also
have a similar wrapper around a `Vector`, that's not the type you get
when accessing `someFileInfo.Version`, you get the `*generated.Vector`
that doesn't have methods, etc.
### Aliasing
```
package protocol
type FileInfo = generated.FileInfo
```
Doesn't help because you can't attach methods to it, plus all the above.
### Generating the types into the target package like we do now and
attaching methods
This fails because of the different shape of the generated type (as in
the embedding case above) plus the generated struct already has a bunch
of methods that we can't necessarily override properly (like `String()`
and a bunch of getters).
### Methods to functions
I considered just moving all the methods we attach to functions in a
specific package, so that for example
```
package protocol
func (f FileInfo) Equal(other FileInfo) bool
```
would become
```
package fileinfos
func Equal(a, b *generated.FileInfo) bool
```
and this would mostly work, but becomes quite verbose and cumbersome,
and somewhat limits discoverability (you can't see what methods are
available on the type in auto completions, etc). In the end I did this
in some cases, like in the database layer where a lot of things like
`func (fv *FileVersion) IsEmpty() bool` becomes `func fvIsEmpty(fv
*generated.FileVersion)` because they were anyway just internal methods.
Fixes #8247
2024-12-01 15:50:17 +00:00
|
|
|
type Iterator func(f protocol.FileInfo) bool
|
2015-01-09 07:18:42 +00:00
|
|
|
|
2022-01-31 09:12:52 +00:00
|
|
|
func NewFileSet(folder string, db *Lowlevel) (*FileSet, error) {
|
2020-12-21 10:32:59 +00:00
|
|
|
select {
|
|
|
|
|
case <-db.oneFileSetCreated:
|
|
|
|
|
default:
|
|
|
|
|
close(db.oneFileSetCreated)
|
|
|
|
|
}
|
2020-12-21 11:59:22 +00:00
|
|
|
meta, err := db.loadMetadataTracker(folder)
|
|
|
|
|
if err != nil {
|
|
|
|
|
db.handleFailure(err)
|
|
|
|
|
return nil, err
|
|
|
|
|
}
|
2020-12-21 10:32:59 +00:00
|
|
|
s := &FileSet{
|
2017-12-14 09:51:17 +00:00
|
|
|
folder: folder,
|
|
|
|
|
db: db,
|
2020-12-21 11:59:22 +00:00
|
|
|
meta: meta,
|
2017-12-14 09:51:17 +00:00
|
|
|
updateMutex: sync.NewMutex(),
|
2015-10-20 13:58:18 +00:00
|
|
|
}
|
2020-12-21 10:32:59 +00:00
|
|
|
if id := s.IndexID(protocol.LocalDeviceID); id == 0 {
|
|
|
|
|
// No index ID set yet. We create one now.
|
|
|
|
|
id = protocol.NewIndexID()
|
|
|
|
|
err := s.db.setIndexID(protocol.LocalDeviceID[:], []byte(s.folder), id)
|
|
|
|
|
if err != nil && !backend.IsClosed(err) {
|
|
|
|
|
fatalError(err, fmt.Sprintf("%s Creating new IndexID", s.folder), s.db)
|
|
|
|
|
}
|
|
|
|
|
}
|
2020-12-21 11:59:22 +00:00
|
|
|
return s, nil
|
2020-02-22 08:36:59 +00:00
|
|
|
}
|
|
|
|
|
|
2017-11-12 20:20:34 +00:00
|
|
|
func (s *FileSet) Drop(device protocol.DeviceID) {
|
2020-08-01 15:32:36 +00:00
|
|
|
opStr := fmt.Sprintf("%s Drop(%v)", s.folder, device)
|
|
|
|
|
l.Debugf(opStr)
|
2016-07-23 18:32:10 +00:00
|
|
|
|
|
|
|
|
s.updateMutex.Lock()
|
|
|
|
|
defer s.updateMutex.Unlock()
|
|
|
|
|
|
2019-11-29 08:11:52 +00:00
|
|
|
if err := s.db.dropDeviceFolder(device[:], []byte(s.folder), s.meta); backend.IsClosed(err) {
|
|
|
|
|
return
|
|
|
|
|
} else if err != nil {
|
2020-09-10 08:54:41 +00:00
|
|
|
fatalError(err, opStr, s.db)
|
2019-11-29 08:11:52 +00:00
|
|
|
}
|
2017-11-12 20:20:34 +00:00
|
|
|
|
2014-10-07 21:15:01 +00:00
|
|
|
if device == protocol.LocalDeviceID {
|
2017-12-14 09:51:17 +00:00
|
|
|
s.meta.resetCounts(device)
|
|
|
|
|
// We deliberately do not reset the sequence number here. Dropping
|
|
|
|
|
// all files for the local device ID only happens in testing - which
|
|
|
|
|
// expects the sequence to be retained, like an old Replace() of all
|
|
|
|
|
// files would do. However, if we ever did it "in production" we
|
|
|
|
|
// would anyway want to retain the sequence for delta indexes to be
|
|
|
|
|
// happy.
|
2017-11-12 20:20:34 +00:00
|
|
|
} else {
|
|
|
|
|
// Here, on the other hand, we want to make sure that any file
|
|
|
|
|
// announced from the remote is newer than our current sequence
|
|
|
|
|
// number.
|
2017-12-14 09:51:17 +00:00
|
|
|
s.meta.resetAll(device)
|
2014-10-07 21:15:01 +00:00
|
|
|
}
|
2017-12-14 09:51:17 +00:00
|
|
|
|
2020-02-13 14:23:08 +00:00
|
|
|
t, err := s.db.newReadWriteTransaction()
|
|
|
|
|
if backend.IsClosed(err) {
|
|
|
|
|
return
|
|
|
|
|
} else if err != nil {
|
2020-09-10 08:54:41 +00:00
|
|
|
fatalError(err, opStr, s.db)
|
2020-02-13 14:23:08 +00:00
|
|
|
}
|
|
|
|
|
defer t.close()
|
|
|
|
|
|
|
|
|
|
if err := s.meta.toDB(t, []byte(s.folder)); backend.IsClosed(err) {
|
|
|
|
|
return
|
|
|
|
|
} else if err != nil {
|
2020-09-10 08:54:41 +00:00
|
|
|
fatalError(err, opStr, s.db)
|
2020-02-13 14:23:08 +00:00
|
|
|
}
|
|
|
|
|
if err := t.Commit(); backend.IsClosed(err) {
|
2019-11-29 08:11:52 +00:00
|
|
|
return
|
|
|
|
|
} else if err != nil {
|
2020-09-10 08:54:41 +00:00
|
|
|
fatalError(err, opStr, s.db)
|
2019-11-29 08:11:52 +00:00
|
|
|
}
|
2014-03-28 13:36:57 +00:00
|
|
|
}
|
|
|
|
|
|
2015-01-12 13:52:24 +00:00
|
|
|
func (s *FileSet) Update(device protocol.DeviceID, fs []protocol.FileInfo) {
|
2020-08-01 15:32:36 +00:00
|
|
|
opStr := fmt.Sprintf("%s Update(%v, [%d])", s.folder, device, len(fs))
|
|
|
|
|
l.Debugf(opStr)
|
2018-01-18 12:40:43 +00:00
|
|
|
|
|
|
|
|
// do not modify fs in place, it is still used in outer scope
|
|
|
|
|
fs = append([]protocol.FileInfo(nil), fs...)
|
|
|
|
|
|
2020-05-16 12:34:53 +00:00
|
|
|
// If one file info is present multiple times, only keep the last.
|
|
|
|
|
// Updating the same file multiple times is problematic, because the
|
|
|
|
|
// previous updates won't yet be represented in the db when we update it
|
|
|
|
|
// again. Additionally even if that problem was taken care of, it would
|
|
|
|
|
// be pointless because we remove the previously added file info again
|
|
|
|
|
// right away.
|
|
|
|
|
fs = normalizeFilenamesAndDropDuplicates(fs)
|
2016-07-23 18:32:10 +00:00
|
|
|
|
|
|
|
|
s.updateMutex.Lock()
|
|
|
|
|
defer s.updateMutex.Unlock()
|
|
|
|
|
|
2019-01-23 09:22:33 +00:00
|
|
|
if device == protocol.LocalDeviceID {
|
|
|
|
|
// For the local device we have a bunch of metadata to track.
|
2019-11-29 08:11:52 +00:00
|
|
|
if err := s.db.updateLocalFiles([]byte(s.folder), fs, s.meta); err != nil && !backend.IsClosed(err) {
|
2020-09-10 08:54:41 +00:00
|
|
|
fatalError(err, opStr, s.db)
|
2019-11-29 08:11:52 +00:00
|
|
|
}
|
2018-09-02 18:58:32 +00:00
|
|
|
return
|
|
|
|
|
}
|
2019-01-23 09:22:33 +00:00
|
|
|
// Easy case, just update the files and we're done.
|
2019-11-29 08:11:52 +00:00
|
|
|
if err := s.db.updateRemoteFiles([]byte(s.folder), device[:], fs, s.meta); err != nil && !backend.IsClosed(err) {
|
2020-09-10 08:54:41 +00:00
|
|
|
fatalError(err, opStr, s.db)
|
2019-11-29 08:11:52 +00:00
|
|
|
}
|
2014-03-28 13:36:57 +00:00
|
|
|
}
|
|
|
|
|
|
2021-11-10 08:46:21 +00:00
|
|
|
func (s *FileSet) RemoveLocalItems(items []string) {
|
|
|
|
|
opStr := fmt.Sprintf("%s RemoveLocalItems([%d])", s.folder, len(items))
|
|
|
|
|
l.Debugf(opStr)
|
|
|
|
|
|
|
|
|
|
s.updateMutex.Lock()
|
|
|
|
|
defer s.updateMutex.Unlock()
|
|
|
|
|
|
|
|
|
|
for i := range items {
|
|
|
|
|
items[i] = osutil.NormalizedFilename(items[i])
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if err := s.db.removeLocalFiles([]byte(s.folder), items, s.meta); err != nil && !backend.IsClosed(err) {
|
|
|
|
|
fatalError(err, opStr, s.db)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2020-01-21 17:23:08 +00:00
|
|
|
type Snapshot struct {
|
2020-09-10 08:54:41 +00:00
|
|
|
folder string
|
|
|
|
|
t readOnlyTransaction
|
|
|
|
|
meta *countsMap
|
|
|
|
|
fatalError func(error, string)
|
2020-01-21 17:23:08 +00:00
|
|
|
}
|
|
|
|
|
|
2021-03-07 12:43:22 +00:00
|
|
|
func (s *FileSet) Snapshot() (*Snapshot, error) {
|
2020-08-01 15:32:36 +00:00
|
|
|
opStr := fmt.Sprintf("%s Snapshot()", s.folder)
|
|
|
|
|
l.Debugf(opStr)
|
2024-04-05 19:32:43 +00:00
|
|
|
|
|
|
|
|
s.updateMutex.Lock()
|
|
|
|
|
defer s.updateMutex.Unlock()
|
|
|
|
|
|
2020-01-21 17:23:08 +00:00
|
|
|
t, err := s.db.newReadOnlyTransaction()
|
|
|
|
|
if err != nil {
|
2021-03-07 12:43:22 +00:00
|
|
|
s.db.handleFailure(err)
|
|
|
|
|
return nil, err
|
2020-01-21 17:23:08 +00:00
|
|
|
}
|
|
|
|
|
return &Snapshot{
|
|
|
|
|
folder: s.folder,
|
|
|
|
|
t: t,
|
|
|
|
|
meta: s.meta.Snapshot(),
|
2020-09-10 08:54:41 +00:00
|
|
|
fatalError: func(err error, opStr string) {
|
|
|
|
|
fatalError(err, opStr, s.db)
|
|
|
|
|
},
|
2021-03-07 12:43:22 +00:00
|
|
|
}, nil
|
2020-01-21 17:23:08 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (s *Snapshot) Release() {
|
|
|
|
|
s.t.close()
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (s *Snapshot) WithNeed(device protocol.DeviceID, fn Iterator) {
|
2020-08-01 15:32:36 +00:00
|
|
|
opStr := fmt.Sprintf("%s WithNeed(%v)", s.folder, device)
|
|
|
|
|
l.Debugf(opStr)
|
2020-01-21 17:23:08 +00:00
|
|
|
if err := s.t.withNeed([]byte(s.folder), device[:], false, nativeFileIterator(fn)); err != nil && !backend.IsClosed(err) {
|
2020-09-10 08:54:41 +00:00
|
|
|
s.fatalError(err, opStr)
|
2019-11-29 08:11:52 +00:00
|
|
|
}
|
2014-08-12 11:53:31 +00:00
|
|
|
}
|
|
|
|
|
|
2020-01-21 17:23:08 +00:00
|
|
|
func (s *Snapshot) WithNeedTruncated(device protocol.DeviceID, fn Iterator) {
|
2020-08-01 15:32:36 +00:00
|
|
|
opStr := fmt.Sprintf("%s WithNeedTruncated(%v)", s.folder, device)
|
|
|
|
|
l.Debugf(opStr)
|
2020-01-21 17:23:08 +00:00
|
|
|
if err := s.t.withNeed([]byte(s.folder), device[:], true, nativeFileIterator(fn)); err != nil && !backend.IsClosed(err) {
|
2020-09-10 08:54:41 +00:00
|
|
|
s.fatalError(err, opStr)
|
2019-11-29 08:11:52 +00:00
|
|
|
}
|
2014-03-28 13:36:57 +00:00
|
|
|
}
|
|
|
|
|
|
2020-01-21 17:23:08 +00:00
|
|
|
func (s *Snapshot) WithHave(device protocol.DeviceID, fn Iterator) {
|
2020-08-01 15:32:36 +00:00
|
|
|
opStr := fmt.Sprintf("%s WithHave(%v)", s.folder, device)
|
|
|
|
|
l.Debugf(opStr)
|
2020-01-21 17:23:08 +00:00
|
|
|
if err := s.t.withHave([]byte(s.folder), device[:], nil, false, nativeFileIterator(fn)); err != nil && !backend.IsClosed(err) {
|
2020-09-10 08:54:41 +00:00
|
|
|
s.fatalError(err, opStr)
|
2019-11-29 08:11:52 +00:00
|
|
|
}
|
2014-08-12 11:53:31 +00:00
|
|
|
}
|
|
|
|
|
|
2020-01-21 17:23:08 +00:00
|
|
|
func (s *Snapshot) WithHaveTruncated(device protocol.DeviceID, fn Iterator) {
|
2020-08-01 15:32:36 +00:00
|
|
|
opStr := fmt.Sprintf("%s WithHaveTruncated(%v)", s.folder, device)
|
|
|
|
|
l.Debugf(opStr)
|
2020-01-21 17:23:08 +00:00
|
|
|
if err := s.t.withHave([]byte(s.folder), device[:], nil, true, nativeFileIterator(fn)); err != nil && !backend.IsClosed(err) {
|
2020-09-10 08:54:41 +00:00
|
|
|
s.fatalError(err, opStr)
|
2019-11-29 08:11:52 +00:00
|
|
|
}
|
2014-03-28 13:36:57 +00:00
|
|
|
}
|
|
|
|
|
|
2020-01-21 17:23:08 +00:00
|
|
|
func (s *Snapshot) WithHaveSequence(startSeq int64, fn Iterator) {
|
2020-08-01 15:32:36 +00:00
|
|
|
opStr := fmt.Sprintf("%s WithHaveSequence(%v)", s.folder, startSeq)
|
|
|
|
|
l.Debugf(opStr)
|
2020-01-21 17:23:08 +00:00
|
|
|
if err := s.t.withHaveSequence([]byte(s.folder), startSeq, nativeFileIterator(fn)); err != nil && !backend.IsClosed(err) {
|
2020-09-10 08:54:41 +00:00
|
|
|
s.fatalError(err, opStr)
|
2019-11-29 08:11:52 +00:00
|
|
|
}
|
2018-05-01 21:39:15 +00:00
|
|
|
}
|
|
|
|
|
|
2018-05-17 07:26:40 +00:00
|
|
|
// Except for an item with a path equal to prefix, only children of prefix are iterated.
|
|
|
|
|
// E.g. for prefix "dir", "dir/file" is iterated, but "dir.file" is not.
|
2020-01-21 17:23:08 +00:00
|
|
|
func (s *Snapshot) WithPrefixedHaveTruncated(device protocol.DeviceID, prefix string, fn Iterator) {
|
2020-08-01 15:32:36 +00:00
|
|
|
opStr := fmt.Sprintf(`%s WithPrefixedHaveTruncated(%v, "%v")`, s.folder, device, prefix)
|
|
|
|
|
l.Debugf(opStr)
|
2020-01-21 17:23:08 +00:00
|
|
|
if err := s.t.withHave([]byte(s.folder), device[:], []byte(osutil.NormalizedFilename(prefix)), true, nativeFileIterator(fn)); err != nil && !backend.IsClosed(err) {
|
2020-09-10 08:54:41 +00:00
|
|
|
s.fatalError(err, opStr)
|
2019-11-29 08:11:52 +00:00
|
|
|
}
|
2016-03-18 12:16:33 +00:00
|
|
|
}
|
2019-11-29 08:11:52 +00:00
|
|
|
|
2020-01-21 17:23:08 +00:00
|
|
|
func (s *Snapshot) WithGlobal(fn Iterator) {
|
2020-08-01 15:32:36 +00:00
|
|
|
opStr := fmt.Sprintf("%s WithGlobal()", s.folder)
|
|
|
|
|
l.Debugf(opStr)
|
2020-01-21 17:23:08 +00:00
|
|
|
if err := s.t.withGlobal([]byte(s.folder), nil, false, nativeFileIterator(fn)); err != nil && !backend.IsClosed(err) {
|
2020-09-10 08:54:41 +00:00
|
|
|
s.fatalError(err, opStr)
|
2019-11-29 08:11:52 +00:00
|
|
|
}
|
2014-08-12 14:17:28 +00:00
|
|
|
}
|
|
|
|
|
|
2020-01-21 17:23:08 +00:00
|
|
|
func (s *Snapshot) WithGlobalTruncated(fn Iterator) {
|
2020-08-01 15:32:36 +00:00
|
|
|
opStr := fmt.Sprintf("%s WithGlobalTruncated()", s.folder)
|
|
|
|
|
l.Debugf(opStr)
|
2020-01-21 17:23:08 +00:00
|
|
|
if err := s.t.withGlobal([]byte(s.folder), nil, true, nativeFileIterator(fn)); err != nil && !backend.IsClosed(err) {
|
2020-09-10 08:54:41 +00:00
|
|
|
s.fatalError(err, opStr)
|
2019-11-29 08:11:52 +00:00
|
|
|
}
|
2015-02-07 10:52:42 +00:00
|
|
|
}
|
|
|
|
|
|
2018-05-17 07:26:40 +00:00
|
|
|
// Except for an item with a path equal to prefix, only children of prefix are iterated.
|
|
|
|
|
// E.g. for prefix "dir", "dir/file" is iterated, but "dir.file" is not.
|
2020-01-21 17:23:08 +00:00
|
|
|
func (s *Snapshot) WithPrefixedGlobalTruncated(prefix string, fn Iterator) {
|
2020-08-01 15:32:36 +00:00
|
|
|
opStr := fmt.Sprintf(`%s WithPrefixedGlobalTruncated("%v")`, s.folder, prefix)
|
|
|
|
|
l.Debugf(opStr)
|
2020-01-21 17:23:08 +00:00
|
|
|
if err := s.t.withGlobal([]byte(s.folder), []byte(osutil.NormalizedFilename(prefix)), true, nativeFileIterator(fn)); err != nil && !backend.IsClosed(err) {
|
2020-09-10 08:54:41 +00:00
|
|
|
s.fatalError(err, opStr)
|
2019-11-29 08:11:52 +00:00
|
|
|
}
|
2014-03-28 13:36:57 +00:00
|
|
|
}
|
|
|
|
|
|
2020-01-21 17:23:08 +00:00
|
|
|
func (s *Snapshot) Get(device protocol.DeviceID, file string) (protocol.FileInfo, bool) {
|
2020-08-01 15:32:36 +00:00
|
|
|
opStr := fmt.Sprintf("%s Get(%v)", s.folder, file)
|
|
|
|
|
l.Debugf(opStr)
|
2020-01-21 17:23:08 +00:00
|
|
|
f, ok, err := s.t.getFile([]byte(s.folder), device[:], []byte(osutil.NormalizedFilename(file)))
|
2019-11-29 08:11:52 +00:00
|
|
|
if backend.IsClosed(err) {
|
|
|
|
|
return protocol.FileInfo{}, false
|
|
|
|
|
} else if err != nil {
|
2020-09-10 08:54:41 +00:00
|
|
|
s.fatalError(err, opStr)
|
2019-11-29 08:11:52 +00:00
|
|
|
}
|
2014-11-05 23:41:51 +00:00
|
|
|
f.Name = osutil.NativeFilename(f.Name)
|
2015-01-06 21:12:45 +00:00
|
|
|
return f, ok
|
2014-03-28 13:36:57 +00:00
|
|
|
}
|
|
|
|
|
|
2020-01-21 17:23:08 +00:00
|
|
|
func (s *Snapshot) GetGlobal(file string) (protocol.FileInfo, bool) {
|
2020-08-01 15:32:36 +00:00
|
|
|
opStr := fmt.Sprintf("%s GetGlobal(%v)", s.folder, file)
|
|
|
|
|
l.Debugf(opStr)
|
2020-01-21 17:23:08 +00:00
|
|
|
_, fi, ok, err := s.t.getGlobal(nil, []byte(s.folder), []byte(osutil.NormalizedFilename(file)), false)
|
2019-11-29 08:11:52 +00:00
|
|
|
if backend.IsClosed(err) {
|
|
|
|
|
return protocol.FileInfo{}, false
|
|
|
|
|
} else if err != nil {
|
2020-09-10 08:54:41 +00:00
|
|
|
s.fatalError(err, opStr)
|
2019-11-29 08:11:52 +00:00
|
|
|
}
|
2015-01-09 07:41:02 +00:00
|
|
|
if !ok {
|
|
|
|
|
return protocol.FileInfo{}, false
|
|
|
|
|
}
|
refactor: use modern Protobuf encoder (#9817)
At a high level, this is what I've done and why:
- I'm moving the protobuf generation for the `protocol`, `discovery` and
`db` packages to the modern alternatives, and using `buf` to generate
because it's nice and simple.
- After trying various approaches on how to integrate the new types with
the existing code, I opted for splitting off our own data model types
from the on-the-wire generated types. This means we can have a
`FileInfo` type with nicer ergonomics and lots of methods, while the
protobuf generated type stays clean and close to the wire protocol. It
does mean copying between the two when required, which certainly adds a
small amount of inefficiency. If we want to walk this back in the future
and use the raw generated type throughout, that's possible, this however
makes the refactor smaller (!) as it doesn't change everything about the
type for everyone at the same time.
- I have simply removed in cold blood a significant number of old
database migrations. These depended on previous generations of generated
messages of various kinds and were annoying to support in the new
fashion. The oldest supported database version now is the one from
Syncthing 1.9.0 from Sep 7, 2020.
- I changed config structs to be regular manually defined structs.
For the sake of discussion, some things I tried that turned out not to
work...
### Embedding / wrapping
Embedding the protobuf generated structs in our existing types as a data
container and keeping our methods and stuff:
```
package protocol
type FileInfo struct {
*generated.FileInfo
}
```
This generates a lot of problems because the internal shape of the
generated struct is quite different (different names, different types,
more pointers), because initializing it doesn't work like you'd expect
(i.e., you end up with an embedded nil pointer and a panic), and because
the types of child types don't get wrapped. That is, even if we also
have a similar wrapper around a `Vector`, that's not the type you get
when accessing `someFileInfo.Version`, you get the `*generated.Vector`
that doesn't have methods, etc.
### Aliasing
```
package protocol
type FileInfo = generated.FileInfo
```
Doesn't help because you can't attach methods to it, plus all the above.
### Generating the types into the target package like we do now and
attaching methods
This fails because of the different shape of the generated type (as in
the embedding case above) plus the generated struct already has a bunch
of methods that we can't necessarily override properly (like `String()`
and a bunch of getters).
### Methods to functions
I considered just moving all the methods we attach to functions in a
specific package, so that for example
```
package protocol
func (f FileInfo) Equal(other FileInfo) bool
```
would become
```
package fileinfos
func Equal(a, b *generated.FileInfo) bool
```
and this would mostly work, but becomes quite verbose and cumbersome,
and somewhat limits discoverability (you can't see what methods are
available on the type in auto completions, etc). In the end I did this
in some cases, like in the database layer where a lot of things like
`func (fv *FileVersion) IsEmpty() bool` becomes `func fvIsEmpty(fv
*generated.FileVersion)` because they were anyway just internal methods.
Fixes #8247
2024-12-01 15:50:17 +00:00
|
|
|
fi.Name = osutil.NativeFilename(fi.Name)
|
|
|
|
|
return fi, true
|
2015-01-09 07:41:02 +00:00
|
|
|
}
|
|
|
|
|
|
refactor: use modern Protobuf encoder (#9817)
At a high level, this is what I've done and why:
- I'm moving the protobuf generation for the `protocol`, `discovery` and
`db` packages to the modern alternatives, and using `buf` to generate
because it's nice and simple.
- After trying various approaches on how to integrate the new types with
the existing code, I opted for splitting off our own data model types
from the on-the-wire generated types. This means we can have a
`FileInfo` type with nicer ergonomics and lots of methods, while the
protobuf generated type stays clean and close to the wire protocol. It
does mean copying between the two when required, which certainly adds a
small amount of inefficiency. If we want to walk this back in the future
and use the raw generated type throughout, that's possible, this however
makes the refactor smaller (!) as it doesn't change everything about the
type for everyone at the same time.
- I have simply removed in cold blood a significant number of old
database migrations. These depended on previous generations of generated
messages of various kinds and were annoying to support in the new
fashion. The oldest supported database version now is the one from
Syncthing 1.9.0 from Sep 7, 2020.
- I changed config structs to be regular manually defined structs.
For the sake of discussion, some things I tried that turned out not to
work...
### Embedding / wrapping
Embedding the protobuf generated structs in our existing types as a data
container and keeping our methods and stuff:
```
package protocol
type FileInfo struct {
*generated.FileInfo
}
```
This generates a lot of problems because the internal shape of the
generated struct is quite different (different names, different types,
more pointers), because initializing it doesn't work like you'd expect
(i.e., you end up with an embedded nil pointer and a panic), and because
the types of child types don't get wrapped. That is, even if we also
have a similar wrapper around a `Vector`, that's not the type you get
when accessing `someFileInfo.Version`, you get the `*generated.Vector`
that doesn't have methods, etc.
### Aliasing
```
package protocol
type FileInfo = generated.FileInfo
```
Doesn't help because you can't attach methods to it, plus all the above.
### Generating the types into the target package like we do now and
attaching methods
This fails because of the different shape of the generated type (as in
the embedding case above) plus the generated struct already has a bunch
of methods that we can't necessarily override properly (like `String()`
and a bunch of getters).
### Methods to functions
I considered just moving all the methods we attach to functions in a
specific package, so that for example
```
package protocol
func (f FileInfo) Equal(other FileInfo) bool
```
would become
```
package fileinfos
func Equal(a, b *generated.FileInfo) bool
```
and this would mostly work, but becomes quite verbose and cumbersome,
and somewhat limits discoverability (you can't see what methods are
available on the type in auto completions, etc). In the end I did this
in some cases, like in the database layer where a lot of things like
`func (fv *FileVersion) IsEmpty() bool` becomes `func fvIsEmpty(fv
*generated.FileVersion)` because they were anyway just internal methods.
Fixes #8247
2024-12-01 15:50:17 +00:00
|
|
|
func (s *Snapshot) GetGlobalTruncated(file string) (protocol.FileInfo, bool) {
|
2020-08-01 15:32:36 +00:00
|
|
|
opStr := fmt.Sprintf("%s GetGlobalTruncated(%v)", s.folder, file)
|
|
|
|
|
l.Debugf(opStr)
|
2020-01-21 17:23:08 +00:00
|
|
|
_, fi, ok, err := s.t.getGlobal(nil, []byte(s.folder), []byte(osutil.NormalizedFilename(file)), true)
|
2019-11-29 08:11:52 +00:00
|
|
|
if backend.IsClosed(err) {
|
refactor: use modern Protobuf encoder (#9817)
At a high level, this is what I've done and why:
- I'm moving the protobuf generation for the `protocol`, `discovery` and
`db` packages to the modern alternatives, and using `buf` to generate
because it's nice and simple.
- After trying various approaches on how to integrate the new types with
the existing code, I opted for splitting off our own data model types
from the on-the-wire generated types. This means we can have a
`FileInfo` type with nicer ergonomics and lots of methods, while the
protobuf generated type stays clean and close to the wire protocol. It
does mean copying between the two when required, which certainly adds a
small amount of inefficiency. If we want to walk this back in the future
and use the raw generated type throughout, that's possible, this however
makes the refactor smaller (!) as it doesn't change everything about the
type for everyone at the same time.
- I have simply removed in cold blood a significant number of old
database migrations. These depended on previous generations of generated
messages of various kinds and were annoying to support in the new
fashion. The oldest supported database version now is the one from
Syncthing 1.9.0 from Sep 7, 2020.
- I changed config structs to be regular manually defined structs.
For the sake of discussion, some things I tried that turned out not to
work...
### Embedding / wrapping
Embedding the protobuf generated structs in our existing types as a data
container and keeping our methods and stuff:
```
package protocol
type FileInfo struct {
*generated.FileInfo
}
```
This generates a lot of problems because the internal shape of the
generated struct is quite different (different names, different types,
more pointers), because initializing it doesn't work like you'd expect
(i.e., you end up with an embedded nil pointer and a panic), and because
the types of child types don't get wrapped. That is, even if we also
have a similar wrapper around a `Vector`, that's not the type you get
when accessing `someFileInfo.Version`, you get the `*generated.Vector`
that doesn't have methods, etc.
### Aliasing
```
package protocol
type FileInfo = generated.FileInfo
```
Doesn't help because you can't attach methods to it, plus all the above.
### Generating the types into the target package like we do now and
attaching methods
This fails because of the different shape of the generated type (as in
the embedding case above) plus the generated struct already has a bunch
of methods that we can't necessarily override properly (like `String()`
and a bunch of getters).
### Methods to functions
I considered just moving all the methods we attach to functions in a
specific package, so that for example
```
package protocol
func (f FileInfo) Equal(other FileInfo) bool
```
would become
```
package fileinfos
func Equal(a, b *generated.FileInfo) bool
```
and this would mostly work, but becomes quite verbose and cumbersome,
and somewhat limits discoverability (you can't see what methods are
available on the type in auto completions, etc). In the end I did this
in some cases, like in the database layer where a lot of things like
`func (fv *FileVersion) IsEmpty() bool` becomes `func fvIsEmpty(fv
*generated.FileVersion)` because they were anyway just internal methods.
Fixes #8247
2024-12-01 15:50:17 +00:00
|
|
|
return protocol.FileInfo{}, false
|
2019-11-29 08:11:52 +00:00
|
|
|
} else if err != nil {
|
2020-09-10 08:54:41 +00:00
|
|
|
s.fatalError(err, opStr)
|
2019-11-29 08:11:52 +00:00
|
|
|
}
|
2015-01-09 07:41:02 +00:00
|
|
|
if !ok {
|
refactor: use modern Protobuf encoder (#9817)
At a high level, this is what I've done and why:
- I'm moving the protobuf generation for the `protocol`, `discovery` and
`db` packages to the modern alternatives, and using `buf` to generate
because it's nice and simple.
- After trying various approaches on how to integrate the new types with
the existing code, I opted for splitting off our own data model types
from the on-the-wire generated types. This means we can have a
`FileInfo` type with nicer ergonomics and lots of methods, while the
protobuf generated type stays clean and close to the wire protocol. It
does mean copying between the two when required, which certainly adds a
small amount of inefficiency. If we want to walk this back in the future
and use the raw generated type throughout, that's possible, this however
makes the refactor smaller (!) as it doesn't change everything about the
type for everyone at the same time.
- I have simply removed in cold blood a significant number of old
database migrations. These depended on previous generations of generated
messages of various kinds and were annoying to support in the new
fashion. The oldest supported database version now is the one from
Syncthing 1.9.0 from Sep 7, 2020.
- I changed config structs to be regular manually defined structs.
For the sake of discussion, some things I tried that turned out not to
work...
### Embedding / wrapping
Embedding the protobuf generated structs in our existing types as a data
container and keeping our methods and stuff:
```
package protocol
type FileInfo struct {
*generated.FileInfo
}
```
This generates a lot of problems because the internal shape of the
generated struct is quite different (different names, different types,
more pointers), because initializing it doesn't work like you'd expect
(i.e., you end up with an embedded nil pointer and a panic), and because
the types of child types don't get wrapped. That is, even if we also
have a similar wrapper around a `Vector`, that's not the type you get
when accessing `someFileInfo.Version`, you get the `*generated.Vector`
that doesn't have methods, etc.
### Aliasing
```
package protocol
type FileInfo = generated.FileInfo
```
Doesn't help because you can't attach methods to it, plus all the above.
### Generating the types into the target package like we do now and
attaching methods
This fails because of the different shape of the generated type (as in
the embedding case above) plus the generated struct already has a bunch
of methods that we can't necessarily override properly (like `String()`
and a bunch of getters).
### Methods to functions
I considered just moving all the methods we attach to functions in a
specific package, so that for example
```
package protocol
func (f FileInfo) Equal(other FileInfo) bool
```
would become
```
package fileinfos
func Equal(a, b *generated.FileInfo) bool
```
and this would mostly work, but becomes quite verbose and cumbersome,
and somewhat limits discoverability (you can't see what methods are
available on the type in auto completions, etc). In the end I did this
in some cases, like in the database layer where a lot of things like
`func (fv *FileVersion) IsEmpty() bool` becomes `func fvIsEmpty(fv
*generated.FileVersion)` because they were anyway just internal methods.
Fixes #8247
2024-12-01 15:50:17 +00:00
|
|
|
return protocol.FileInfo{}, false
|
2015-01-09 07:41:02 +00:00
|
|
|
}
|
refactor: use modern Protobuf encoder (#9817)
At a high level, this is what I've done and why:
- I'm moving the protobuf generation for the `protocol`, `discovery` and
`db` packages to the modern alternatives, and using `buf` to generate
because it's nice and simple.
- After trying various approaches on how to integrate the new types with
the existing code, I opted for splitting off our own data model types
from the on-the-wire generated types. This means we can have a
`FileInfo` type with nicer ergonomics and lots of methods, while the
protobuf generated type stays clean and close to the wire protocol. It
does mean copying between the two when required, which certainly adds a
small amount of inefficiency. If we want to walk this back in the future
and use the raw generated type throughout, that's possible, this however
makes the refactor smaller (!) as it doesn't change everything about the
type for everyone at the same time.
- I have simply removed in cold blood a significant number of old
database migrations. These depended on previous generations of generated
messages of various kinds and were annoying to support in the new
fashion. The oldest supported database version now is the one from
Syncthing 1.9.0 from Sep 7, 2020.
- I changed config structs to be regular manually defined structs.
For the sake of discussion, some things I tried that turned out not to
work...
### Embedding / wrapping
Embedding the protobuf generated structs in our existing types as a data
container and keeping our methods and stuff:
```
package protocol
type FileInfo struct {
*generated.FileInfo
}
```
This generates a lot of problems because the internal shape of the
generated struct is quite different (different names, different types,
more pointers), because initializing it doesn't work like you'd expect
(i.e., you end up with an embedded nil pointer and a panic), and because
the types of child types don't get wrapped. That is, even if we also
have a similar wrapper around a `Vector`, that's not the type you get
when accessing `someFileInfo.Version`, you get the `*generated.Vector`
that doesn't have methods, etc.
### Aliasing
```
package protocol
type FileInfo = generated.FileInfo
```
Doesn't help because you can't attach methods to it, plus all the above.
### Generating the types into the target package like we do now and
attaching methods
This fails because of the different shape of the generated type (as in
the embedding case above) plus the generated struct already has a bunch
of methods that we can't necessarily override properly (like `String()`
and a bunch of getters).
### Methods to functions
I considered just moving all the methods we attach to functions in a
specific package, so that for example
```
package protocol
func (f FileInfo) Equal(other FileInfo) bool
```
would become
```
package fileinfos
func Equal(a, b *generated.FileInfo) bool
```
and this would mostly work, but becomes quite verbose and cumbersome,
and somewhat limits discoverability (you can't see what methods are
available on the type in auto completions, etc). In the end I did this
in some cases, like in the database layer where a lot of things like
`func (fv *FileVersion) IsEmpty() bool` becomes `func fvIsEmpty(fv
*generated.FileVersion)` because they were anyway just internal methods.
Fixes #8247
2024-12-01 15:50:17 +00:00
|
|
|
fi.Name = osutil.NativeFilename(fi.Name)
|
|
|
|
|
return fi, true
|
2014-03-28 13:36:57 +00:00
|
|
|
}
|
|
|
|
|
|
2020-01-21 17:23:08 +00:00
|
|
|
func (s *Snapshot) Availability(file string) []protocol.DeviceID {
|
2020-08-01 15:32:36 +00:00
|
|
|
opStr := fmt.Sprintf("%s Availability(%v)", s.folder, file)
|
|
|
|
|
l.Debugf(opStr)
|
2020-01-21 17:23:08 +00:00
|
|
|
av, err := s.t.availability([]byte(s.folder), []byte(osutil.NormalizedFilename(file)))
|
2019-11-29 08:11:52 +00:00
|
|
|
if backend.IsClosed(err) {
|
|
|
|
|
return nil
|
|
|
|
|
} else if err != nil {
|
2020-09-10 08:54:41 +00:00
|
|
|
s.fatalError(err, opStr)
|
2019-11-29 08:11:52 +00:00
|
|
|
}
|
|
|
|
|
return av
|
2014-03-28 13:36:57 +00:00
|
|
|
}
|
|
|
|
|
|
refactor: use modern Protobuf encoder (#9817)
At a high level, this is what I've done and why:
- I'm moving the protobuf generation for the `protocol`, `discovery` and
`db` packages to the modern alternatives, and using `buf` to generate
because it's nice and simple.
- After trying various approaches on how to integrate the new types with
the existing code, I opted for splitting off our own data model types
from the on-the-wire generated types. This means we can have a
`FileInfo` type with nicer ergonomics and lots of methods, while the
protobuf generated type stays clean and close to the wire protocol. It
does mean copying between the two when required, which certainly adds a
small amount of inefficiency. If we want to walk this back in the future
and use the raw generated type throughout, that's possible, this however
makes the refactor smaller (!) as it doesn't change everything about the
type for everyone at the same time.
- I have simply removed in cold blood a significant number of old
database migrations. These depended on previous generations of generated
messages of various kinds and were annoying to support in the new
fashion. The oldest supported database version now is the one from
Syncthing 1.9.0 from Sep 7, 2020.
- I changed config structs to be regular manually defined structs.
For the sake of discussion, some things I tried that turned out not to
work...
### Embedding / wrapping
Embedding the protobuf generated structs in our existing types as a data
container and keeping our methods and stuff:
```
package protocol
type FileInfo struct {
*generated.FileInfo
}
```
This generates a lot of problems because the internal shape of the
generated struct is quite different (different names, different types,
more pointers), because initializing it doesn't work like you'd expect
(i.e., you end up with an embedded nil pointer and a panic), and because
the types of child types don't get wrapped. That is, even if we also
have a similar wrapper around a `Vector`, that's not the type you get
when accessing `someFileInfo.Version`, you get the `*generated.Vector`
that doesn't have methods, etc.
### Aliasing
```
package protocol
type FileInfo = generated.FileInfo
```
Doesn't help because you can't attach methods to it, plus all the above.
### Generating the types into the target package like we do now and
attaching methods
This fails because of the different shape of the generated type (as in
the embedding case above) plus the generated struct already has a bunch
of methods that we can't necessarily override properly (like `String()`
and a bunch of getters).
### Methods to functions
I considered just moving all the methods we attach to functions in a
specific package, so that for example
```
package protocol
func (f FileInfo) Equal(other FileInfo) bool
```
would become
```
package fileinfos
func Equal(a, b *generated.FileInfo) bool
```
and this would mostly work, but becomes quite verbose and cumbersome,
and somewhat limits discoverability (you can't see what methods are
available on the type in auto completions, etc). In the end I did this
in some cases, like in the database layer where a lot of things like
`func (fv *FileVersion) IsEmpty() bool` becomes `func fvIsEmpty(fv
*generated.FileVersion)` because they were anyway just internal methods.
Fixes #8247
2024-12-01 15:50:17 +00:00
|
|
|
func (s *Snapshot) DebugGlobalVersions(file string) *DebugVersionList {
|
2020-11-10 08:24:45 +00:00
|
|
|
opStr := fmt.Sprintf("%s DebugGlobalVersions(%v)", s.folder, file)
|
|
|
|
|
l.Debugf(opStr)
|
|
|
|
|
vl, err := s.t.getGlobalVersions(nil, []byte(s.folder), []byte(osutil.NormalizedFilename(file)))
|
2021-03-30 18:06:01 +00:00
|
|
|
if backend.IsClosed(err) || backend.IsNotFound(err) {
|
refactor: use modern Protobuf encoder (#9817)
At a high level, this is what I've done and why:
- I'm moving the protobuf generation for the `protocol`, `discovery` and
`db` packages to the modern alternatives, and using `buf` to generate
because it's nice and simple.
- After trying various approaches on how to integrate the new types with
the existing code, I opted for splitting off our own data model types
from the on-the-wire generated types. This means we can have a
`FileInfo` type with nicer ergonomics and lots of methods, while the
protobuf generated type stays clean and close to the wire protocol. It
does mean copying between the two when required, which certainly adds a
small amount of inefficiency. If we want to walk this back in the future
and use the raw generated type throughout, that's possible, this however
makes the refactor smaller (!) as it doesn't change everything about the
type for everyone at the same time.
- I have simply removed in cold blood a significant number of old
database migrations. These depended on previous generations of generated
messages of various kinds and were annoying to support in the new
fashion. The oldest supported database version now is the one from
Syncthing 1.9.0 from Sep 7, 2020.
- I changed config structs to be regular manually defined structs.
For the sake of discussion, some things I tried that turned out not to
work...
### Embedding / wrapping
Embedding the protobuf generated structs in our existing types as a data
container and keeping our methods and stuff:
```
package protocol
type FileInfo struct {
*generated.FileInfo
}
```
This generates a lot of problems because the internal shape of the
generated struct is quite different (different names, different types,
more pointers), because initializing it doesn't work like you'd expect
(i.e., you end up with an embedded nil pointer and a panic), and because
the types of child types don't get wrapped. That is, even if we also
have a similar wrapper around a `Vector`, that's not the type you get
when accessing `someFileInfo.Version`, you get the `*generated.Vector`
that doesn't have methods, etc.
### Aliasing
```
package protocol
type FileInfo = generated.FileInfo
```
Doesn't help because you can't attach methods to it, plus all the above.
### Generating the types into the target package like we do now and
attaching methods
This fails because of the different shape of the generated type (as in
the embedding case above) plus the generated struct already has a bunch
of methods that we can't necessarily override properly (like `String()`
and a bunch of getters).
### Methods to functions
I considered just moving all the methods we attach to functions in a
specific package, so that for example
```
package protocol
func (f FileInfo) Equal(other FileInfo) bool
```
would become
```
package fileinfos
func Equal(a, b *generated.FileInfo) bool
```
and this would mostly work, but becomes quite verbose and cumbersome,
and somewhat limits discoverability (you can't see what methods are
available on the type in auto completions, etc). In the end I did this
in some cases, like in the database layer where a lot of things like
`func (fv *FileVersion) IsEmpty() bool` becomes `func fvIsEmpty(fv
*generated.FileVersion)` because they were anyway just internal methods.
Fixes #8247
2024-12-01 15:50:17 +00:00
|
|
|
return nil
|
2020-11-10 08:24:45 +00:00
|
|
|
} else if err != nil {
|
|
|
|
|
s.fatalError(err, opStr)
|
|
|
|
|
}
|
refactor: use modern Protobuf encoder (#9817)
At a high level, this is what I've done and why:
- I'm moving the protobuf generation for the `protocol`, `discovery` and
`db` packages to the modern alternatives, and using `buf` to generate
because it's nice and simple.
- After trying various approaches on how to integrate the new types with
the existing code, I opted for splitting off our own data model types
from the on-the-wire generated types. This means we can have a
`FileInfo` type with nicer ergonomics and lots of methods, while the
protobuf generated type stays clean and close to the wire protocol. It
does mean copying between the two when required, which certainly adds a
small amount of inefficiency. If we want to walk this back in the future
and use the raw generated type throughout, that's possible, this however
makes the refactor smaller (!) as it doesn't change everything about the
type for everyone at the same time.
- I have simply removed in cold blood a significant number of old
database migrations. These depended on previous generations of generated
messages of various kinds and were annoying to support in the new
fashion. The oldest supported database version now is the one from
Syncthing 1.9.0 from Sep 7, 2020.
- I changed config structs to be regular manually defined structs.
For the sake of discussion, some things I tried that turned out not to
work...
### Embedding / wrapping
Embedding the protobuf generated structs in our existing types as a data
container and keeping our methods and stuff:
```
package protocol
type FileInfo struct {
*generated.FileInfo
}
```
This generates a lot of problems because the internal shape of the
generated struct is quite different (different names, different types,
more pointers), because initializing it doesn't work like you'd expect
(i.e., you end up with an embedded nil pointer and a panic), and because
the types of child types don't get wrapped. That is, even if we also
have a similar wrapper around a `Vector`, that's not the type you get
when accessing `someFileInfo.Version`, you get the `*generated.Vector`
that doesn't have methods, etc.
### Aliasing
```
package protocol
type FileInfo = generated.FileInfo
```
Doesn't help because you can't attach methods to it, plus all the above.
### Generating the types into the target package like we do now and
attaching methods
This fails because of the different shape of the generated type (as in
the embedding case above) plus the generated struct already has a bunch
of methods that we can't necessarily override properly (like `String()`
and a bunch of getters).
### Methods to functions
I considered just moving all the methods we attach to functions in a
specific package, so that for example
```
package protocol
func (f FileInfo) Equal(other FileInfo) bool
```
would become
```
package fileinfos
func Equal(a, b *generated.FileInfo) bool
```
and this would mostly work, but becomes quite verbose and cumbersome,
and somewhat limits discoverability (you can't see what methods are
available on the type in auto completions, etc). In the end I did this
in some cases, like in the database layer where a lot of things like
`func (fv *FileVersion) IsEmpty() bool` becomes `func fvIsEmpty(fv
*generated.FileVersion)` because they were anyway just internal methods.
Fixes #8247
2024-12-01 15:50:17 +00:00
|
|
|
return &DebugVersionList{vl}
|
2020-11-10 08:24:45 +00:00
|
|
|
}
|
|
|
|
|
|
2020-01-21 17:23:08 +00:00
|
|
|
func (s *Snapshot) Sequence(device protocol.DeviceID) int64 {
|
|
|
|
|
return s.meta.Counts(device, 0).Sequence
|
2014-03-28 13:36:57 +00:00
|
|
|
}
|
2014-08-15 10:52:16 +00:00
|
|
|
|
lib/api: Improve folder summary event, verbose service (#9370)
This makes a couple of small improvements to the folder summary
mechanism:
- The folder summary includes the local and remote sequence numbers in
clear text, rather than some odd sum that I'm not sure what it was
intended to represent.
- The folder summary event is generated when appropriate, regardless of
whether there is an event listener. We did this before because
generating it was expensive, and we wanted to avoid doing it
unnecessarily. Nowadays, however, it's mostly just reading out
pre-calculated metadata, and anyway, it's nice if it shows up reliably
when running with -verbose.
The point of all this is to make it easier to use these events to judge
when devices are, in fact, in sync. As-is, if I'm looking at two
devices, it's very difficult to reliably determine if they are in sync
or not. The reason is that while we can ask device A if it thinks it's
in sync, we can't see if the answer is "yes" because it has processed
all changes from B, or if it just doesn't know about the changes from B
yet. With proper sequence numbers in the event we can compare the two
and determine the truth. This makes testing a lot easier.
2024-01-31 07:24:39 +00:00
|
|
|
// RemoteSequences returns a map of the sequence numbers seen for each
|
|
|
|
|
// remote device sharing this folder.
|
|
|
|
|
func (s *Snapshot) RemoteSequences() map[protocol.DeviceID]int64 {
|
|
|
|
|
res := make(map[protocol.DeviceID]int64)
|
2020-01-21 17:23:08 +00:00
|
|
|
for _, device := range s.meta.devices() {
|
lib/api: Improve folder summary event, verbose service (#9370)
This makes a couple of small improvements to the folder summary
mechanism:
- The folder summary includes the local and remote sequence numbers in
clear text, rather than some odd sum that I'm not sure what it was
intended to represent.
- The folder summary event is generated when appropriate, regardless of
whether there is an event listener. We did this before because
generating it was expensive, and we wanted to avoid doing it
unnecessarily. Nowadays, however, it's mostly just reading out
pre-calculated metadata, and anyway, it's nice if it shows up reliably
when running with -verbose.
The point of all this is to make it easier to use these events to judge
when devices are, in fact, in sync. As-is, if I'm looking at two
devices, it's very difficult to reliably determine if they are in sync
or not. The reason is that while we can ask device A if it thinks it's
in sync, we can't see if the answer is "yes" because it has processed
all changes from B, or if it just doesn't know about the changes from B
yet. With proper sequence numbers in the event we can compare the two
and determine the truth. This makes testing a lot easier.
2024-01-31 07:24:39 +00:00
|
|
|
switch device {
|
|
|
|
|
case protocol.EmptyDeviceID, protocol.LocalDeviceID, protocol.GlobalDeviceID:
|
|
|
|
|
continue
|
|
|
|
|
default:
|
|
|
|
|
if seq := s.Sequence(device); seq > 0 {
|
|
|
|
|
res[device] = seq
|
|
|
|
|
}
|
|
|
|
|
}
|
2020-01-21 17:23:08 +00:00
|
|
|
}
|
|
|
|
|
|
lib/api: Improve folder summary event, verbose service (#9370)
This makes a couple of small improvements to the folder summary
mechanism:
- The folder summary includes the local and remote sequence numbers in
clear text, rather than some odd sum that I'm not sure what it was
intended to represent.
- The folder summary event is generated when appropriate, regardless of
whether there is an event listener. We did this before because
generating it was expensive, and we wanted to avoid doing it
unnecessarily. Nowadays, however, it's mostly just reading out
pre-calculated metadata, and anyway, it's nice if it shows up reliably
when running with -verbose.
The point of all this is to make it easier to use these events to judge
when devices are, in fact, in sync. As-is, if I'm looking at two
devices, it's very difficult to reliably determine if they are in sync
or not. The reason is that while we can ask device A if it thinks it's
in sync, we can't see if the answer is "yes" because it has processed
all changes from B, or if it just doesn't know about the changes from B
yet. With proper sequence numbers in the event we can compare the two
and determine the truth. This makes testing a lot easier.
2024-01-31 07:24:39 +00:00
|
|
|
return res
|
2020-01-21 17:23:08 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (s *Snapshot) LocalSize() Counts {
|
2018-07-12 08:15:57 +00:00
|
|
|
local := s.meta.Counts(protocol.LocalDeviceID, 0)
|
2020-01-21 17:23:08 +00:00
|
|
|
return local.Add(s.ReceiveOnlyChangedSize())
|
2018-07-12 08:15:57 +00:00
|
|
|
}
|
|
|
|
|
|
2020-01-21 17:23:08 +00:00
|
|
|
func (s *Snapshot) ReceiveOnlyChangedSize() Counts {
|
2018-07-12 08:15:57 +00:00
|
|
|
return s.meta.Counts(protocol.LocalDeviceID, protocol.FlagLocalReceiveOnly)
|
2015-10-21 07:10:26 +00:00
|
|
|
}
|
|
|
|
|
|
2020-01-21 17:23:08 +00:00
|
|
|
func (s *Snapshot) GlobalSize() Counts {
|
2020-07-30 11:49:14 +00:00
|
|
|
return s.meta.Counts(protocol.GlobalDeviceID, 0)
|
2015-10-21 07:10:26 +00:00
|
|
|
}
|
|
|
|
|
|
2020-05-11 13:07:06 +00:00
|
|
|
func (s *Snapshot) NeedSize(device protocol.DeviceID) Counts {
|
|
|
|
|
return s.meta.Counts(device, needFlag)
|
2020-01-21 17:23:08 +00:00
|
|
|
}
|
|
|
|
|
|
2020-05-11 18:15:11 +00:00
|
|
|
func (s *Snapshot) WithBlocksHash(hash []byte, fn Iterator) {
|
2020-08-01 15:32:36 +00:00
|
|
|
opStr := fmt.Sprintf(`%s WithBlocksHash("%x")`, s.folder, hash)
|
|
|
|
|
l.Debugf(opStr)
|
2020-05-11 18:15:11 +00:00
|
|
|
if err := s.t.withBlocksHash([]byte(s.folder), hash, nativeFileIterator(fn)); err != nil && !backend.IsClosed(err) {
|
2020-09-10 08:54:41 +00:00
|
|
|
s.fatalError(err, opStr)
|
2020-05-11 18:15:11 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2020-01-21 17:23:08 +00:00
|
|
|
func (s *FileSet) Sequence(device protocol.DeviceID) int64 {
|
|
|
|
|
return s.meta.Sequence(device)
|
|
|
|
|
}
|
|
|
|
|
|
2016-07-23 12:46:31 +00:00
|
|
|
func (s *FileSet) IndexID(device protocol.DeviceID) protocol.IndexID {
|
2020-08-01 15:32:36 +00:00
|
|
|
opStr := fmt.Sprintf("%s IndexID(%v)", s.folder, device)
|
|
|
|
|
l.Debugf(opStr)
|
2019-11-29 08:11:52 +00:00
|
|
|
id, err := s.db.getIndexID(device[:], []byte(s.folder))
|
|
|
|
|
if backend.IsClosed(err) {
|
|
|
|
|
return 0
|
|
|
|
|
} else if err != nil {
|
2020-09-10 08:54:41 +00:00
|
|
|
fatalError(err, opStr, s.db)
|
2019-11-29 08:11:52 +00:00
|
|
|
}
|
2016-07-23 12:46:31 +00:00
|
|
|
return id
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (s *FileSet) SetIndexID(device protocol.DeviceID, id protocol.IndexID) {
|
|
|
|
|
if device == protocol.LocalDeviceID {
|
|
|
|
|
panic("do not explicitly set index ID for local device")
|
|
|
|
|
}
|
2020-08-01 15:32:36 +00:00
|
|
|
opStr := fmt.Sprintf("%s SetIndexID(%v, %v)", s.folder, device, id)
|
|
|
|
|
l.Debugf(opStr)
|
2019-11-29 08:11:52 +00:00
|
|
|
if err := s.db.setIndexID(device[:], []byte(s.folder), id); err != nil && !backend.IsClosed(err) {
|
2020-09-10 08:54:41 +00:00
|
|
|
fatalError(err, opStr, s.db)
|
2019-11-29 08:11:52 +00:00
|
|
|
}
|
2016-07-23 12:46:31 +00:00
|
|
|
}
|
|
|
|
|
|
2022-04-10 18:55:05 +00:00
|
|
|
func (s *FileSet) MtimeOption() fs.Option {
|
|
|
|
|
opStr := fmt.Sprintf("%s MtimeOption()", s.folder)
|
2020-08-01 15:32:36 +00:00
|
|
|
l.Debugf(opStr)
|
2019-11-29 08:11:52 +00:00
|
|
|
prefix, err := s.db.keyer.GenerateMtimesKey(nil, []byte(s.folder))
|
|
|
|
|
if backend.IsClosed(err) {
|
|
|
|
|
return nil
|
|
|
|
|
} else if err != nil {
|
2020-09-10 08:54:41 +00:00
|
|
|
fatalError(err, opStr, s.db)
|
2019-11-29 08:11:52 +00:00
|
|
|
}
|
2019-12-02 07:18:04 +00:00
|
|
|
kv := NewNamespacedKV(s.db, string(prefix))
|
2022-04-10 18:55:05 +00:00
|
|
|
return fs.NewMtimeOption(kv)
|
2016-08-05 17:45:45 +00:00
|
|
|
}
|
|
|
|
|
|
2016-08-07 16:21:59 +00:00
|
|
|
func (s *FileSet) ListDevices() []protocol.DeviceID {
|
2017-12-14 09:51:17 +00:00
|
|
|
return s.meta.devices()
|
2016-07-23 12:46:31 +00:00
|
|
|
}
|
|
|
|
|
|
2020-03-18 16:34:46 +00:00
|
|
|
func (s *FileSet) RepairSequence() (int, error) {
|
|
|
|
|
s.updateAndGCMutexLock() // Ensures consistent locking order
|
|
|
|
|
defer s.updateMutex.Unlock()
|
|
|
|
|
defer s.db.gcMut.RUnlock()
|
|
|
|
|
return s.db.repairSequenceGCLocked(s.folder, s.meta)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (s *FileSet) updateAndGCMutexLock() {
|
|
|
|
|
s.updateMutex.Lock()
|
|
|
|
|
s.db.gcMut.RLock()
|
|
|
|
|
}
|
|
|
|
|
|
2014-09-28 11:00:38 +00:00
|
|
|
// DropFolder clears out all information related to the given folder from the
|
2014-08-31 11:34:17 +00:00
|
|
|
// database.
|
2019-12-02 07:18:04 +00:00
|
|
|
func DropFolder(db *Lowlevel, folder string) {
|
2020-08-01 15:32:36 +00:00
|
|
|
opStr := fmt.Sprintf("DropFolder(%v)", folder)
|
|
|
|
|
l.Debugf(opStr)
|
2019-11-29 08:11:52 +00:00
|
|
|
droppers := []func([]byte) error{
|
|
|
|
|
db.dropFolder,
|
|
|
|
|
db.dropMtimes,
|
|
|
|
|
db.dropFolderMeta,
|
2020-12-21 10:10:59 +00:00
|
|
|
db.dropFolderIndexIDs,
|
2019-11-29 08:11:52 +00:00
|
|
|
db.folderIdx.Delete,
|
|
|
|
|
}
|
|
|
|
|
for _, drop := range droppers {
|
|
|
|
|
if err := drop([]byte(folder)); backend.IsClosed(err) {
|
|
|
|
|
return
|
|
|
|
|
} else if err != nil {
|
2020-09-10 08:54:41 +00:00
|
|
|
fatalError(err, opStr, db)
|
2019-11-29 08:11:52 +00:00
|
|
|
}
|
|
|
|
|
}
|
2018-10-10 09:34:24 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// DropDeltaIndexIDs removes all delta index IDs from the database.
|
|
|
|
|
// This will cause a full index transmission on the next connection.
|
2020-12-21 10:32:59 +00:00
|
|
|
// Must be called before using FileSets, i.e. before NewFileSet is called for
|
|
|
|
|
// the first time.
|
2018-10-10 09:34:24 +00:00
|
|
|
func DropDeltaIndexIDs(db *Lowlevel) {
|
2020-12-21 10:32:59 +00:00
|
|
|
select {
|
|
|
|
|
case <-db.oneFileSetCreated:
|
|
|
|
|
panic("DropDeltaIndexIDs must not be called after NewFileSet for the same Lowlevel")
|
|
|
|
|
default:
|
|
|
|
|
}
|
2020-08-01 15:32:36 +00:00
|
|
|
opStr := "DropDeltaIndexIDs"
|
|
|
|
|
l.Debugf(opStr)
|
2021-05-15 09:13:39 +00:00
|
|
|
err := db.dropIndexIDs()
|
2019-11-29 08:11:52 +00:00
|
|
|
if backend.IsClosed(err) {
|
|
|
|
|
return
|
|
|
|
|
} else if err != nil {
|
2020-09-10 08:54:41 +00:00
|
|
|
fatalError(err, opStr, db)
|
2019-11-29 08:11:52 +00:00
|
|
|
}
|
2014-08-31 11:34:17 +00:00
|
|
|
}
|
|
|
|
|
|
2020-05-16 12:34:53 +00:00
|
|
|
func normalizeFilenamesAndDropDuplicates(fs []protocol.FileInfo) []protocol.FileInfo {
|
|
|
|
|
positions := make(map[string]int, len(fs))
|
|
|
|
|
for i, f := range fs {
|
|
|
|
|
norm := osutil.NormalizedFilename(f.Name)
|
|
|
|
|
if pos, ok := positions[norm]; ok {
|
|
|
|
|
fs[pos] = protocol.FileInfo{}
|
|
|
|
|
}
|
|
|
|
|
positions[norm] = i
|
|
|
|
|
fs[i].Name = norm
|
|
|
|
|
}
|
|
|
|
|
for i := 0; i < len(fs); {
|
|
|
|
|
if fs[i].Name == "" {
|
|
|
|
|
fs = append(fs[:i], fs[i+1:]...)
|
|
|
|
|
continue
|
|
|
|
|
}
|
|
|
|
|
i++
|
2014-08-15 10:52:16 +00:00
|
|
|
}
|
2020-05-16 12:34:53 +00:00
|
|
|
return fs
|
2014-08-15 10:52:16 +00:00
|
|
|
}
|
|
|
|
|
|
2015-01-09 07:18:42 +00:00
|
|
|
func nativeFileIterator(fn Iterator) Iterator {
|
refactor: use modern Protobuf encoder (#9817)
At a high level, this is what I've done and why:
- I'm moving the protobuf generation for the `protocol`, `discovery` and
`db` packages to the modern alternatives, and using `buf` to generate
because it's nice and simple.
- After trying various approaches on how to integrate the new types with
the existing code, I opted for splitting off our own data model types
from the on-the-wire generated types. This means we can have a
`FileInfo` type with nicer ergonomics and lots of methods, while the
protobuf generated type stays clean and close to the wire protocol. It
does mean copying between the two when required, which certainly adds a
small amount of inefficiency. If we want to walk this back in the future
and use the raw generated type throughout, that's possible, this however
makes the refactor smaller (!) as it doesn't change everything about the
type for everyone at the same time.
- I have simply removed in cold blood a significant number of old
database migrations. These depended on previous generations of generated
messages of various kinds and were annoying to support in the new
fashion. The oldest supported database version now is the one from
Syncthing 1.9.0 from Sep 7, 2020.
- I changed config structs to be regular manually defined structs.
For the sake of discussion, some things I tried that turned out not to
work...
### Embedding / wrapping
Embedding the protobuf generated structs in our existing types as a data
container and keeping our methods and stuff:
```
package protocol
type FileInfo struct {
*generated.FileInfo
}
```
This generates a lot of problems because the internal shape of the
generated struct is quite different (different names, different types,
more pointers), because initializing it doesn't work like you'd expect
(i.e., you end up with an embedded nil pointer and a panic), and because
the types of child types don't get wrapped. That is, even if we also
have a similar wrapper around a `Vector`, that's not the type you get
when accessing `someFileInfo.Version`, you get the `*generated.Vector`
that doesn't have methods, etc.
### Aliasing
```
package protocol
type FileInfo = generated.FileInfo
```
Doesn't help because you can't attach methods to it, plus all the above.
### Generating the types into the target package like we do now and
attaching methods
This fails because of the different shape of the generated type (as in
the embedding case above) plus the generated struct already has a bunch
of methods that we can't necessarily override properly (like `String()`
and a bunch of getters).
### Methods to functions
I considered just moving all the methods we attach to functions in a
specific package, so that for example
```
package protocol
func (f FileInfo) Equal(other FileInfo) bool
```
would become
```
package fileinfos
func Equal(a, b *generated.FileInfo) bool
```
and this would mostly work, but becomes quite verbose and cumbersome,
and somewhat limits discoverability (you can't see what methods are
available on the type in auto completions, etc). In the end I did this
in some cases, like in the database layer where a lot of things like
`func (fv *FileVersion) IsEmpty() bool` becomes `func fvIsEmpty(fv
*generated.FileVersion)` because they were anyway just internal methods.
Fixes #8247
2024-12-01 15:50:17 +00:00
|
|
|
return func(fi protocol.FileInfo) bool {
|
|
|
|
|
fi.Name = osutil.NativeFilename(fi.Name)
|
|
|
|
|
return fn(fi)
|
2014-08-15 10:52:16 +00:00
|
|
|
}
|
|
|
|
|
}
|
2020-08-01 15:32:36 +00:00
|
|
|
|
2020-09-10 08:54:41 +00:00
|
|
|
func fatalError(err error, opStr string, db *Lowlevel) {
|
2020-12-21 11:59:22 +00:00
|
|
|
db.checkErrorForRepair(err)
|
2020-10-19 06:40:37 +00:00
|
|
|
l.Warnf("Fatal error: %v: %v", opStr, err)
|
2020-12-21 11:59:22 +00:00
|
|
|
panic(ldbPathRe.ReplaceAllString(err.Error(), "$1 x: "))
|
2020-08-01 15:32:36 +00:00
|
|
|
}
|
refactor: use modern Protobuf encoder (#9817)
At a high level, this is what I've done and why:
- I'm moving the protobuf generation for the `protocol`, `discovery` and
`db` packages to the modern alternatives, and using `buf` to generate
because it's nice and simple.
- After trying various approaches on how to integrate the new types with
the existing code, I opted for splitting off our own data model types
from the on-the-wire generated types. This means we can have a
`FileInfo` type with nicer ergonomics and lots of methods, while the
protobuf generated type stays clean and close to the wire protocol. It
does mean copying between the two when required, which certainly adds a
small amount of inefficiency. If we want to walk this back in the future
and use the raw generated type throughout, that's possible, this however
makes the refactor smaller (!) as it doesn't change everything about the
type for everyone at the same time.
- I have simply removed in cold blood a significant number of old
database migrations. These depended on previous generations of generated
messages of various kinds and were annoying to support in the new
fashion. The oldest supported database version now is the one from
Syncthing 1.9.0 from Sep 7, 2020.
- I changed config structs to be regular manually defined structs.
For the sake of discussion, some things I tried that turned out not to
work...
### Embedding / wrapping
Embedding the protobuf generated structs in our existing types as a data
container and keeping our methods and stuff:
```
package protocol
type FileInfo struct {
*generated.FileInfo
}
```
This generates a lot of problems because the internal shape of the
generated struct is quite different (different names, different types,
more pointers), because initializing it doesn't work like you'd expect
(i.e., you end up with an embedded nil pointer and a panic), and because
the types of child types don't get wrapped. That is, even if we also
have a similar wrapper around a `Vector`, that's not the type you get
when accessing `someFileInfo.Version`, you get the `*generated.Vector`
that doesn't have methods, etc.
### Aliasing
```
package protocol
type FileInfo = generated.FileInfo
```
Doesn't help because you can't attach methods to it, plus all the above.
### Generating the types into the target package like we do now and
attaching methods
This fails because of the different shape of the generated type (as in
the embedding case above) plus the generated struct already has a bunch
of methods that we can't necessarily override properly (like `String()`
and a bunch of getters).
### Methods to functions
I considered just moving all the methods we attach to functions in a
specific package, so that for example
```
package protocol
func (f FileInfo) Equal(other FileInfo) bool
```
would become
```
package fileinfos
func Equal(a, b *generated.FileInfo) bool
```
and this would mostly work, but becomes quite verbose and cumbersome,
and somewhat limits discoverability (you can't see what methods are
available on the type in auto completions, etc). In the end I did this
in some cases, like in the database layer where a lot of things like
`func (fv *FileVersion) IsEmpty() bool` becomes `func fvIsEmpty(fv
*generated.FileVersion)` because they were anyway just internal methods.
Fixes #8247
2024-12-01 15:50:17 +00:00
|
|
|
|
|
|
|
|
// DebugFileVersion is the database-internal representation of a file
|
|
|
|
|
// version, with a nicer string representation, used only by API debug
|
|
|
|
|
// methods.
|
|
|
|
|
type DebugVersionList struct {
|
|
|
|
|
*dbproto.VersionList
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (vl DebugVersionList) String() string {
|
|
|
|
|
var b bytes.Buffer
|
|
|
|
|
var id protocol.DeviceID
|
|
|
|
|
b.WriteString("[")
|
|
|
|
|
for i, v := range vl.Versions {
|
|
|
|
|
if i > 0 {
|
|
|
|
|
b.WriteString(", ")
|
|
|
|
|
}
|
|
|
|
|
fmt.Fprintf(&b, "{Version:%v, Deleted:%v, Devices:[", protocol.VectorFromWire(v.Version), v.Deleted)
|
|
|
|
|
for j, dev := range v.Devices {
|
|
|
|
|
if j > 0 {
|
|
|
|
|
b.WriteString(", ")
|
|
|
|
|
}
|
|
|
|
|
copy(id[:], dev)
|
|
|
|
|
fmt.Fprint(&b, id.Short())
|
|
|
|
|
}
|
|
|
|
|
b.WriteString("], Invalid:[")
|
|
|
|
|
for j, dev := range v.InvalidDevices {
|
|
|
|
|
if j > 0 {
|
|
|
|
|
b.WriteString(", ")
|
|
|
|
|
}
|
|
|
|
|
copy(id[:], dev)
|
|
|
|
|
fmt.Fprint(&b, id.Short())
|
|
|
|
|
}
|
|
|
|
|
fmt.Fprint(&b, "]}")
|
|
|
|
|
}
|
|
|
|
|
b.WriteString("]")
|
|
|
|
|
return b.String()
|
|
|
|
|
}
|
