You can authenticate with GitHub to vote. (We will request "user profile" and "public repositories" access scope because that's the minimum to be able to post votes.) You can also vote directly on GitHub using the š reaction, though it'll take about an hour to reflect here.
Local Directory Sync, in which the feature: * Synchronizes two or more (2+) local directories * Allows āhybrid synchronization,ā such as synchronizing the above two or more local directories with a single network sync folder * Abides by the same rules, logic, and parameters currently used by Syncthing for network Folder syncs.
Itās probably time to investigate decentralizing discovery. Doing so would reduce our infrastructure burden and reduce centralized knowledge of the network. In a DHT we want to be able to look up the contact details for a given device ID. We want to publish our own contact details into the DHT. We donāt necessarily want to make it simple for a passive observer to map the entire network, so it would be nice if the contact details were encrypted.
Storing Data in S3/Object Store backend to utilize redundancy and cheaper storage costs when hosting the server in the cloud. And using the untrusted node feature the cloud instance can serve as a secure centralized reliable distribution point that can also serve as backup and provide increased bandwidth.
Problem to Solve: In the current version of Syncthing, when two computers (letās name them A and B) have unsynchronized folders due to disconnection, and they have some different files, there isnāt a direct way to:
As a user, I want to sync filenames containing reserved/unsupported/special characters on any filesystem. Specifically, I want to sync filenames containing "*:<>?| characters on NTFS/exFAT/FAT32 filesystems, which disallows these characters in filenames. These filesystems are most often found on Windows and Android systems, but any system may have attached media using these formats.
Configurable commands or scripts to run at various point in a file life cycle.
As sourced in #4209, Folder Paths are not editable in Syncthing, and are not editable due to āpotential deletion of files,ā etc.. I personally donāt agree with this stance taken by devs, and believe users should be given an option to change folder paths.
As a user I would like to see the number of conflicting files in the (web-)UI so that Iām aware of having conflicting files in the first place.
I would suggest to introduce a global ignore list, that has some default entries. For example: .git/ # ignore git repros .sparkleshare/ # ignore git sparkleshare .~lock. # ignore LibreOffice lock files .owncloudsync # ignore owncloud
I want to ignore a set of files on all my nodes. Right now, the only āhalf workaroundā is adding the line #include .stglobalignore
Iāve setup a very long Full Rescan Interval for my folders but when I restart Syncthing, all folders are scanned even when they have already been scanned within this interval. If this is intentional, please add a setting to disable this.
As of now you can only see how many files are included in your local/global state but not which ones.
Currently, when setting up a new device, it goes something like this: 1. add the folder 2. manually setup an ignore rule that ignores all files except the ignore-file I need 3. wait for the ignore-file to be synced 4. include the ignore-file in .stignore and let the sync proceed
This has come up a lot in the forum but thereās no issue for it here that I can find. Weāve evolved the rate limits a couple of times and this is something that many/most other rate limiting things have. There is a workaround in using something to periodically reconfigure via the API, but this is not realistically something most users can accomplish.
It would be neat if Syncthing, when starting after an upgrade, showed the release notes as a dismissible āwhatās newā dialog.
Currently ignores are stored in $FOLDER/.stignore. I propose moving them inside the folder marker, for example $FOLDER/.stfolder/ignore.txt. There are a couple of advantages to this:
I just read a sad story of someone losing all their files due to misunderstanding the nature of Syncthing and what would happen on side B when files are deleted on side A. Itās not the first such story Iāve seen. We can say that this is a user misunderstanding and they should be more careful, and there is truth in that. Yet, we can fairly easily prevent some anguish here.
Since current speed and bytes left are already here it would be great to use them to calculate an ETA for download/upload of each folder and also show the time left for the sync status of each device. After successful transfers this line is hidden.
Currently cmd/syncthing contains a shitload of stuff. This makes sense as is, but complicates reuse. What reuse? Possibilities:
Iām working on setting up Syncthing to use as my own video game cloud save host. I want to be able to sync all the games that donāt have some sort of cloud saves already implemented. This is obviously possible but itās a bit unwieldy without being able to use symlinks to push it all into one synced folder, especially if you want to sync the files somewhere other than your default directory and canāt just rely on auto-accepts.
Currently discovery and relay are working in a global mode by default. When setting up SyncThing on my NAS and devices (desktop and mobile) I intended to build a sync mechanism that works on my local network only - without any need of a cloud or other kinds of public access.
I want a tool that behaves like rsync, but with the advantages of syncthing:
When syncing we build a queue of the files to sync, then sort it according to the desired criteria (size, time, random, etc.). For millions of files this can use a lot of RAM. In some cases we donāt really care too much about the exact order and it would be better to use less RAM. For this, we could have a limit on the queue size. When doing a pull and iterating over the database / need list, we stop iterating once the limit is reached. The pull proceeds as normal. When complete, we do another pass and grab more needed files, repeat until done.
I would like to request a feature to enable the special handling of hard links, namely overwrite them in-place.
I am aware that currently Syncthing doesnāt care about hard links, it treats them as regular files and when updating such files it writes to a temp file, deletes the old file and renames the temp file. As a consequence every file that has multiple hard links gets detached from the original content and other links.
But sometimes there is a need to use content with multiple names (in separate directories), and this over-weighs the possible risk of file corruption that could rise from direct updating the content of such files.
I would suggest an option (e.g: inPlaceOverwriteHardLinks or something alike) that can be enabled on any share, so that files with link count greater than 1 are overwritten in place.
I was recently cleaning up my file system and noticed a .stfolder in one of my directories. I erroneously assumed this was a folder created by the Spring Tools Suite IDE, so I removed the directory. Syncthing eventually let me know that the folder in question was no longer in sync due to a missing file/folder (which seemed to be .stfolder).
How about this:
- a link format that contains a device id and a folder id (eg syncthing://add/*device-id*/*folder-id*)
- a way to generate such links in syncthing
- a way to add this link into syncthing (either a text field to paste it in, or a link handler for syncthing://)
On Linux, ? and : are valid characters for filenames. On Android, they are not. As a result, the files cannot be written. My current setup: syncing files between my Linux laptop and Android phone. I tried to sync files that had :ās and ?ās in their names. The sync failed without giving useful error codes.
It would be nice to define remote device addresses via SRV records. The benefit would be to easily change destination and port without requiring manual intervention on the other devices.
I would like a command that blocks until the current folder is fully synchronized.
This issue has been touched upon a couple times, but I thought I should make it a bit clearer with my use case, and ask for comments on feasibility.
Currently, Syncthing needs an .stignore file to store files to be ignored as well as an .stversions folder to store previous versions. This is in addition to the fact that Syncthing requires a .stfolder inside every folder to be functional. Could all these files be consolidated into one folder? This would reduce clutter in each folder and make things a bit easier to understand for users. It would also bring syncthing in line with how other folder based tools such as git function (all related data under a .git folder in each repo)
There is a good chance the WAN IPv6 address will be faster than the WAN IPv4 address, for the following reasons:
I just tried SyncThing (actually SyncTrayzor, but I guess there is no real difference) and after initial configuration I think itās really an awesome software. But Iād still hesitate to recommend it to novice users, because I still had to read the āGetting startedā and parts of the FAQ. I guess novice users would not do that - and thatās a pitty.
Laptops with SIM cards/mobile phone functionality are becoming more common, as are hybrid devices like Microsoft surface. These have arguably the same need for not syncing on metered connections as well as not syncing while discharging, but sadly that seems to be locked away into external wrappers like syncthing for Android.
Hello, Iāve been using Syncthing for years and I work in an environment in which I usually rename or move files and folders; unfortunately this results in huge sizes of the .stversions folder, because every renaming or moving is considered a change in the file/directory. Iāve read a lot of posts about this (some date back to 2015!) and a lot of people have my same problem. I totally understand that this is expected behavior, but Iām asking if thereās the possibility to add an option in the file versioning settings, in which the user can decide if this kind of operations (moving and renaming) should be versioned in the .stversion folder or not. I personally think that a lot of people would benefit from this, since it would save sometimes hundreds of GB of space and lot of CPU work for something often not necessary (for example if I rename a 500 GB folder, Syncthing will copy 500 GB of the same data in the .stversion folder, practically doubling the space occupied for no reason).
[Feature Request] Currently Master Folders are really āuntouchableā. If anything goes out of sync, we have an āoverwriteā button to enforce masterās image on all clients.
please add an option to set device itself as āuntrustedā and when ever it is connected it should say āIām a untrusted device, please check the untrusted by defaultā. this would prevent accidentally adding directory in clear.
A lot of services are today deployed with containers on multiple machines. When looking at various containers like tools and databases, they all provide an option to set username/password up front via environment variables to make deployments easier.
Syncthing now checks if there is enough free space (megabytes or %) before syncing folder. This information is determined from the statistics about whole disk/partition (correct me if Iām wrong).
Implement the metrics for the relay service, like it is in the discovery server.
Scenario: I have enabled āSend Onlyā mode for a repository and is out of date (new files).
Iām surprised this hasnāt been requested already, but I didnāt find any real matching issuesā¦
As mentioned in https://github.com/syncthing/syncthing-android/issues/192 , some filenames are not accepted by windows hosts because they contain āspecial charactersā like colons or bars.
Hi. I have 6 network interfaces on my laptop (4 vpns). And I donāt want send local discovering packages to vpn network. I think that it will be good features. And listen these interfaces also doesnāt have sens. Thanks.
It would be nice if the web front-end of syncthing offers browser push notifications, similar to how it works for websites such as Youtube and Facebook.
First of all, many thanks for Syncthing. It is a very useful tool indeed.
Sometimes itās useful to have a portable setup: one where the Syncthing installation, config, database, keys, and files to be synced all live on some kind of removable media that moves around. Currently, this is possible, you just have to create a script to launch Syncthing, setting variables for the home directory and parameters for home and database etc., and take good care when configuring the folder paths. All of that is a bit annoying, and above the pay grade for many users, especially on Windows itās not always obvious how and which variables to set to change the supposed āhome directoryā. We could make this simpler.
Background: We use Syncthing (extremely satisfied, btw!) in a small team of staff members within the organisationās local network & VPN. Each staff member runs one instance on their laptop, and two instances run on our servers (one on-premise, one cloud/VPS).
https://relays.syncthing.net/ currently shows relayed data since the node started. This makes it hard to draw conclusions about how frequently accessed a node really is as the uptime among nodes is somewhere between 0 and 17k hours.
I want to sync files between two devices, but they are rarely turned on at the same time. I donāt want to introduce another device that will hold a full copy of all these files. My phone on the other hand is always turned on but doesnāt have enough space for the whole folder. The idea is to add the folder from my desktop to my phone and set the folder type to temporary. This folder then keeps track of files missing on other devices. When files between other devices are out of sync, the folder is used to temporarily saves those files until they are in sync again. Additionally, there should be a setting for maximum folder size.
The discovery server could make connection tests to the announced addresses/ports and return the result to the client when it does the announcement. This could provide one small part of the āconnection doctorā like functionality, in that Syncthing could display an indicator for success/failure.
Currently we just show disconnected devices as disconnected. Figuring out why they are disconnected, especially when you know the other device is powered on, is a tricky exercise. We should have a āTestā button next to the Edit on disconnected devices. When pressed, it would tell Syncthing do to a connection test and present a modal with something like
Renaming folders makes syncthing to retransmit all of its content to other machines. I thought it could just to rename a folder on clients instead of that. Version used: v1.26.0, (windows and linux)
The versioning system in SyncThing is great, but sometimes one does not want to version everything. In my case it is a Thunderbird profile folder that (for backup purposes) is syncād as part of a larger parent directory. For that directory and (most of) its subdirectory, versioning is in place. But for the TB Profile directory this results in a lot of space being consumed. Perhaps not the best reason for this feature, but it is a reasonā¦ That feature would be that you can specify (in some way) that some directories need not by versioned, although syncād. I see roughly two ways of dealing with this: either a file like .stignore containing regex patterns, or the (probably) more simpler approach of allowing the user to create a directory inside the .stversions directory with a marker signalling that that everything in that directory needs not be versioned. Something like:
syncdir--+
|-.stversions--+
| |-dir_a--+
| | |-file_1.221117...
| | |-...
| |
| |-dir_b--+
| | |-.stdisable_versions
| |
| |-dir_c--+
| | |-file_1.221021....
... ... ...
I could see this happen in lib/versioner/util.go where archiveFile does a check if the directory to move the versioned file to exists and if not, creates it. That could be prepended by a check for the existence of .stdisable_versions in any of the parent directories. I have, unfortunately, not enough knowledge of the Go language to prepare a code block for this.
With existing shared folders between devices, have the function to automatically convert the existing folder from unencrypted (Trusted) to encrypted (untrusted) when entering a password for that folder (and/or device?). Also have this when done in revers (from encrypted to un-encrypted when removing the password).
The error āfolder marker missingā is kind of vague. Looking around, it means that the ā .stfolder ā file is missing.
The current way of replacing the magic default string with something large and incomprehensible is, frankly, crap. This becomes more urgent as itās the only sane way to disable KCP. One suggestion:
Users may not be aware that the .stversions folder persists after switching off file versioning. As itās hidden they might not realise it is still present. Syncthing could display a prompt on the main web UI to delete this folder.
Iāve got a situation where Iāve got a file with two conflicts. Those two conflicted files have the same sha1sum, which differs from the original file.
I have a couple of feature requests for the out-of-sync-items screen. I hope they are not too much trouble.
Hi. Iāve been experiencing good reliability syncing Maildirs with Syncthing for a few weeks already - however, from time to time an occasional empty mail may now show up in my IMAP folders/e-mail client. I suspect that this is due to the partial transfers and/or temp files being read by dovecot (perhaps locking them somehow could help with this?). I was able to ignore dovecotās index files in Syncthing using .stignore, but I canāt seem to find any way to ignore Syncthingās temp files (~syncthing~
feat(gui): list features together in remote device information (#10376)
Currently our API returns JSON responses. In principle those are machine readable of course. We also have a set of protobuf types, for example a large one to represent our Configuration. Hence one might suppose that it should be possible to interpret the result of /rest/system/config using the configuration.proto definition however, unfortunately, one would be wrong. Various minor inconsistencies all add up to make it not work and not be trivially fixable:
First discussed in https://forum.syncthing.net/t/syncthing-does-not-use-all-cpu-cores/18667
Syncthing version: v1.18.1 Browser: Firefox 91.0.2
Not relying on CoW for different ignores. There are a few send-only syncthing shares from the same directory.
How to reproduce:
Today, if I have a thousand peers sharing a folder and announce a file with n blocks in it, Iāll get n * thousand block requests back. Each of those requests will do a number of sanity checks, database lookups and, in the end, file reads before being responded to.
Weāve had some bugs lately that are caused by races in config handling. As it looks today we have
When using Syncthing from a mobile browser, pressing the back button should close the current modal. At the moment, pressing the back button will always navigate to the previous page (away from Syncthing). To me, that isnāt the expected behaviour. Tested with latest Firefox and Chrome on Android.
When a pair removes my device, or removes my device out of a folder, I should be notified so that I can choose to stop automatically ask him to come back again (i.e. depending on my answer, my device would remove either the pair or only the pair in the folder[ās|sā] list (and optionally removes the folder(s) whose pair list is then empty).
Some strings are not in Transifex, e.g. āAutomatically upgraded to version āv0.14.xxā. Restarting in 1 minuteā and some others shown when upgrading. Could those be added?
Currently for a sync folder one can only see the time at witch interval the folder is scanned. E.g. 600 seconds. Idea is to add a countdown timer.
I think it would be useful to choose if a folder is Sent/receive/both, at sharing level. I meant when, in a folder detail, we choose to who share it. For example, i could share to some friends the folder in send_only, but with one that collaborates in manintaining it, in send_receive Right now we can decide only at folder level, se we have to share it two times
FAT filesystems store timestamps in reference to whatever the computer considers local time. This means that when time changes due to daylight savings the timestamps all shift by one hour in some direction, causing files to be rehashed and resynced (at least metadata wise).
Initial multipath TCP support was merged into golang recently which should make its usage quite convenient: https://github.com/golang/go/issues/56539
Iām concerned about the maximum storage need of Staggered File Versioning. If I understand correctly, for the first 1 hour alone a maximum um 120 copies might be kept, and for the first day 24 additional, meaning with only 1 day Maximum Age, one would need to ensure the 144 fold storage space of the synced folder to be save. Otherwise an adversary (human or software e.g. ransomware) can prevent any syncing by flooding the versioned storage. While I do not doubt that there are use cases where the current setup is ideal and either backed by sufficient storage or the risk is acceptable, I would like to suggest and ask for making the staggered intervals configurable, which would be also in general a welcome increase in flexibility with very limited additional code complexity.
Currently if you have many devices and/or folders and you want to edit their settings in succession it requires a lot of clicks - expand item, open modal, close modal, repeat.
config.xml, including the own one, which normally has no option to be paused, have been changed to <paused>true</paused>.<paused>true</paused>.<paused>false</paused> is to use the āResume Allā button (or modify the config file).Right now, when removing a folder from Syncthing, the remaining ~syncthing~xxx.tmp files are left alone on the disc. I think that it would be a good idea to have Syncthing automatically delete them when the folder is being removed as well.
(This is my first bug report on syncthing. I apologize if I am not using the correct terms. I am happy to correct the report and, of course, to add any information I have neglected to include.)
When using the recommended way to set Syncthing up to automatically start and run in background in Windows with Task Scheduler following the official guide under https://docs.syncthing.net/users/autostart.html#autostart-windows-taskschd, ending the task does not stop Syncthing from running in background.
In the XML format config, folders and devices have some settings as attributes and some as child elements. This is somewhat arbitrary, originally maybe based on what felt like āimportantā or āsmallā config settings perhaps. I suggest straightening this out by moving all attributes except id into elements. That is, a folder like:
Currently when a new share is (automatically) accepted the generated name on disk is the āhumanā name of the share, falling back to the ID if that exists on disk already. Iād like an option to always use the ID (and possibly inverse the fallback then? not sure if that would be useful).
Apparently it just supports cloning whole files, and using filepaths instead of open file descriptors at that. Nonetheless that will do for our versioning requirements.
This is an enhancement request. Itās goal is to make Syncthing less dependent on the discovery services always being available.
Whether or not to compress data should be decided on a folder basis not by device.
Iāve been thinking about adding for wrappers (eg the Android app). We could put these stats into a seperate category for each wrapper. Some things that would be interesting: - CPU architecture - always run in background / only run on wifi / only run on battery / restrict to wifi networks - using root - use tor - keep CPU awake - run with foreground priority
Hi,
The āUpload Rateā and āDownload Rateā for the other devices in the GUI are confusing. The numbers show how much data weāre download from / uploading to that device, but the layout implies that the numbers relate to that deviceās total upload/download rate.
I would like to see a folder option from the syncthing GUI to empty the trash can or stored versions manually, if file versioning is used. It is easy to forget about the hidden folders stored there, thus one with bigger files may think about to run out of space.
In some situations it may be desirable to for the device TLS key to be stored on disk in encrypted format. This then requires inputing a key at each startup to unlock the key. The code is fairly simple, we have the technology in the Go stdlib. User experience wise, this could be implemented in two phases.
I have three folders, all up-to-date.
i get out of sync flags for some folders - sometimes there are file names, sometimes not. what is the explanation for the absence? if there are filenames, they are names of files appearing on some other device - could you include a hint which device is holding the file which is not update? this would make it much simpler to correct the problem by, e.g., deleting the offending file.
Syncthingās default UI shows a QR code - which is great. However, it has no feature to scan a qr code from another device. So I can show it, but the other device canāt scane it.
Syncthing would always scan and rehash all files fo figure out if they are changed.. like in the initial scan. This could also be configured for certain filetypes/filenames
I got some 5k of ignored files and I would like to see them. When I click on unsynced items a list of files (~300) display and that is all I can see, it would be cool to have option to list all of the files or have them exported somewhere through terminal etc.
Is it time for a syncthing url format? It would also make setting up shared repos a little easier.
This adds support for loading ignore files remotely on initial folder setup. That is, itās fine to create a folder with an .stignore that says #include some-other-file, as long as some-other-file is available from a peer device.
Based on https://github.com/syncthing/syncthing/issues/9371#issuecomment-1940259377
Currently (with Syncthing 1.27.2), all cookies emitted by the Syncthing Web UI are accessible to JavaScript running in the browser (and thus susceptible to tampering / stealing via potential XSS issues).
Making use of multiple links was a stated goal of https://github.com/syncthing/syncthing/pull/8918. I wonder if thatās actually working with link-aggregation protocols like LACP?
I noticed that Syncthing is not syncing permission 4755 (IgnorePermissions disabled). Is this by design, and if so why?
The āThis Deviceā section on the right side of the dashboard has a link / on click feature on the device id field in the āIdentification Columnā.
With #8728 we gained the ability to detect that syncthing is running inside a container. It would be nice to gather this information for https://data.syncthing.net
Awesome work on landing xattr support in Syncthing! Iāve been trying it out and think cross-platform syncing would be a nice addition.
Came up here: https://forum.syncthing.net/t/untrusted-device-default-scan-timing/18766
Continuing the (lengthy) discussion from https://github.com/syncthing/syncthing/issues/8443#issuecomment-1197320918 here.
Currently the queue order (āsmallest firstā, ānewest firstā, etc) is rather best-effort as the queue is built at one time, and then processed (which can take a long time). During processing any new index updates are effectively ignored until the previously built queue is completed. It would be nice if we could count on a system pulling a small file fairly soon after announcement, if it is configured for smallest-first.
I would love to see the GUI support WebAuthn as an alternative to password authentication. Although the Syncthing GUI perhaps doesnāt need the strongest security since itās typically not exposed to the whole internet, WebAuthn can still offer a much more pleasant user experience than passwords for those users that prefer it. Personally I use a password manager protected by a YubiKey, and itās rather annoying to have to take the detour through the password manager when I could just tap the YubiKey instead - especially when accessing the Syncthing GUI remotely on my phone, I wouldnāt have to switch back and forth between apps to retrieve a password.
On Windows, it is possible to enable NTFS compression per file or per folder, and in the latter case it is also possible to exclude specific files inside a folder from being compressed.
To simplify, Iām synchronising two folders foo and bar between a laptop (with ID LAPTOP) and a server (with ID SERVER) which I recently migrated from an old server (with ID OLD_SERVER) that is still in my list of devices because I forgot to remove it.
A user who has selected āEdit Folderā might reasonably expect to be able to edit the folder path. Yet, one cannot do that. The path is greyed out. That is some indication that one cannot edit the path, and, yet, one is within the āedit folderā option. So how about adding text that says that the path is uneditable? The window already shows a note about the path - see this screenshot:
The systemd service included with syncthing can only be enabled if SELinux is disabled:
what problem your new feature would solve
With over 300 relays worldwide our map is getting cluttered:
This is related to ā[Feature request] ACME (letsencrypt) Support #2445ā. ACME letsencrypt support for the syncthing discovery server would be very convenient in containerized environments. It is very inconvenient to use bind mounts or secrets in docker swarm to map certificates into a container. Ideally, the LetsEncrypt feature should resemble how Traefik does enrolment and renewal.
Right now, it seems that files are always marked as āupdatedā under the āLatest Changeā in the Web GUI, even if this is the very first synchronisation and they are being downloaded to the device for the first time. While not a big deal, I think that it would be nice to have a distinction between actually updating existing files and creating new ones.
I misconfigured the Addresses field in a client, and left off the double slash, entering something like:
tcp:1.2.3.4:5678
rather than
tcp://1.2.3.4:5678
This is not exactly a bug per se, but is it really necessary to list all these addresses under a remote device when the connection has failed?
You have a a function called āallowednetworksā ( https://docs.syncthing.net/advanced/device-allowednetworks.html ) under the devices, a new function called ādeniednetworksā (or other simlar naming to be kept in line with naming schemes) to deny allowing connections via certain IPs, as for example a VPN connection when a relay or direct connection would work better. The current solution I have to do is setup iptables rules to block TCP and UDP trafiic in regards to the IP for syncthing currently and a simpile command to block it from trying to connect via that IP would be much better.
I have ST running on my laptop. I was trying to sync for a whole day unsuccessfuly. Then I looked at console window and saw panic messages due to corrupt database. So, what is happening.
Due to multiple external drives and HDDs, if I have concurrency set to -1 there is a huge amount of thrashing due to lots of folders trying to scan. However if I set them to concurrency 3, all the USB drive perform better, but often the really big sync (>1Tb) on HDDs are having to wait there turn. This could be days.
(Please refer to https://forum.syncthing.net/t/completely-prevent-syncthing-from-traversing-a-directory-subtree/15060 for context.)
To see whether I am also affected by #6614 I checked my homeserver (āunfortunatelyā not affected) and found this:
Whilst each folder has the ability to show what is downloading, I would like to see a global download progress box, similar to Syntrazors FileTransferTrayViewModel,
On Windows, for folders that have many files, a file change can trigger a scan which takes an inordinate amount of time to complete. Until the scan completes, no further syncs occur.
https://docs.syncthing.net/users/ignoring.html says: > On Mac OS and Windows, patterns are always case-insensitive.
Since the ppc64el community is growing thanks to more affordable hardware being produced by companies such as Raptor Computing Systems, it would be fantastic to see support for this architecture added to the Debian/Ubuntu repos.
There are cases when itās useful to have devices that are accepted but where we attempt no outgoing connections.
Given issues #5578, #5633, #5695 we should take a good look at how and when to use \\?\ prefixing. My gut feeling is that we never need it any more and should 1) remove such prefixes when parsing the config and 2) remove any such prefixes coming from external sources (REST, fswatcher, etc.).
Would be possible to extend the autoNormalize functionality to make the desired UTF-8 normalization form selectable? Thanks.
Specification advises that Name, GenericName, Comment and Keywords entries in .desktop fileās [Desktop Entry] section are localestring. This calls for adding language-specific lines, i.e.:
GenericName[en]=File synchronization
GenericName[sv]=Filsynkronisering
GenericName[ru]=Š”ŠøŠ½Ń
ŃŠ¾Š½ŠøŠ·Š°ŃŠøŃ ŃŠ°Š¹Š»Š¾Š²
Naturally, this all should be utilizing the current transifex process.
Today I came across a device that had lots of panic logs (a few minutes apart) because another program had filled up the RAM. I only noticed that because the uptime was less than a minute. Usually the user checks the device every few days via GUI but of course does not look at uptime. It would be great if Syncthing informs the user via a simple warning message that there has been an unclean shutdown/restart. This would be a great help for users that only use the GUI, thanks!
For example when we have two addresses for a device - one which is correct but slow to connect, and one which connects quickly but doesnāt work. Typically the ādoesnāt workā one can be an address that gets rejected after connection by IP ACL, or one that is looped back by mis-announcement (#5151) or NAT router.
Currently (v0.14.49, Linux (64 bit)), the UI for a āFolderā or āRemote deviceā consists of a roll up/down window with several buttons at the bottom (e.g. āPauseā, āEditā, etc.).
When adding about a GB of files to a folder, I, on a whim, checked the āOut of syncā modal on some of the target devices. Furthermore, I decided to jump to the last page, as nothing of note would occur on the first pages.
Currently folders and devices are always sorted on label/ID. When there are a lot of them, being able to sort based on sync status (and then label/ID as secondary) would be useful.
As per https://github.com/syncthing/syncthing/pull/4886#issuecomment-382076308:
Checking the behavior thatād be present at each version update once https://github.com/syncthing/syncthing/commit/d4b7be009c3cbae61b67a0306ff9f0d9d845bfe3 is in release, I noticed the following:
Hi there,
The new restoration feature in the GUI is huge, especially for less technical users I talked to who were regularily overwhelmed with restoring bigger folder structures which got deleted by accident. But everything is better now!
In case of Error on folder "ā¦" (ā¦): folder path missing case 1. from https://github.com/syncthing/syncthing/issues/4309#issuecomment-327869090 can be assumed to be true. So this FR may be functionally similar, but smaller in scope. Thus, it could serve as an experiment to gather experience, and prepare making the paths of normally syncing folders editable.
If Syncthing maintained an āexternal index fileā, i.e. something like a syncthing-index.txt{.gz} in the folder root,
When one displays DLāing items by 10 (or 25 / 50), only about the 10 first have the clickable arrow to push the DL to top.
I would be nice to be able to set a max disk size for a folder shared with somebody so it doesnāt eat all the available space in the system.
As syncthing re-use existing data instead of downloading them when the data block is already on disk, I think it will be great to see the ācopyingā speed rate too.
I just ran syncthing v0.14.16 for the first time in a while and it auto-updated to v0.14.19. Problem is the new syncthing.exe did not have the same permissions as syncthing.exe.old. Specifically my user did not have permission to execute the file. I can reproduce this problem by running syncthing.exe -upgrade (with an older version so it actually does the upgrade.)
Currently, the discovery server does not support any access control mechanisms.
Hi, thank you for implementing the global and local state of the folders. Now one can easiely see, if they are synced or not. But when there are lots of files, the text isnāt readable completely (see screenshot). The same issue is with ālast changeā.
Would be good to know how much time remaining when syncing to/from remote devices
Currently syncthing will reconnect and rescan folder when periodical or manual rescan is requested. Iād like a feature to just reconnect folder without rescanning and then follow the folderās rescan interval settings.
In addition to global and local discovery, try any addresses weāve recently seen a given device use.
For the last few days when I tried to sync a 10GB folder with a lot of subfolders and different sized files the status of the folder was just āScanningā Iād really appreciate it when itād actually show me if there was any progress made (showing hashed filename) or itās just stuck.
Currently, thereās no distinction between āHello, I need to send this message but Iām intending to close the connection straight afterwards because I donāt know you, or because I have you pausedā and āHello, all looks good from my side, letās syncā.
On OS X at least, the system keychain is a secure way to store secrets. Secure in that itās encrypted at rest but transparently accessible to the application when the user has logged in and authenticated.
Or send a specific message IndexUpdateFinished to notify that there wonāt be any more index updates coming.
I am currently using Syncthing over a slow connection, and I have 2 files in the queue - one big and one small. The small was created later then the big one and the big one has started syncing already. I see no easy way to āpauseā the sync of the big file to allow small file to get synced first (I want it first, because the big one will take 2 days to sync). I tried changing the pull order but it does not affect already started transfers - the app restarts and continues syncing the big file.
Sequence of events: 1. syncthing starts 2. Tcp listener starts, blocks on upnp searches 3. Relay listener starts, connects, notifies discovery āhey addresses availableā 4. Discovery publishes that the device is only avilable via relay 5. Some other device looks up addresses and causes them to get cached
Reason: typing in a very long path is not fun. This would be handy for filling in the path of a folder in case the path is extremely deep in the folder structure. This would also help newbies as well as they might not know what a path is. I get complaints from people saying this program is too hard and that I should email them let;letās say 15 gig zip files. That wonāt happen any time soon.
So that we could introduce API changes more easier.
This is one of a number of proposals which are supposed to make it easier for beginners to get a working share setup. For reference: https://forum.syncthing.net/t/different-view-on-security-perspective/6678/38
Add a folder option to only perform any action (sync/scan/ā¦) if the .stfolder contains a magic file with a magic content.
Currently a folder is āidleā as long as we are up to date with the cluster, regardless of what anyone else is doing. It could potentially be useful to show the folder as āuploadingā if weāve received a block request to it within the last x seconds. The interval would need to be long enough to prevent flapping in the common case yet short enough to fall back to āidleā in reasonable time once everyone is in sync.
Within major versions we should retain compatibility for REST API clients. This means not removing fields and keeping values on the same format. (I think adding fields is allowed in JSON?)
$ ~/bin/syncthing/syncthing -upgrade-to https://github.com/syncthing/syncthing/releases/download/v0.12.0-beta1/syncthing-linux-amd64-v0.12.0-beta1.tar.gz
14:48:07 OK: Upgraded from https://github.com/syncthing/syncthing/releases/download/v0.12.0-beta1/syncthing-linux-amd64-v0.12.0-beta1.tar.gz
The āout of syncā dialog only supplies a filename. This is not helpful for determining if it is appropriate or safe to click āoverride changesā.
We should add a list of connected applications in the about dialog (or somewhere else). This enables applications to register themselves to show their version number and a support url. See https://github.com/syncthing/syncthing-inotify/issues/65 for a use case.
Would be nice to have an Information about which File was sent lately (Per Folder) I know this is not really easy because of the P2P Feature. But it could at least show the Filename from the last sent Blocks (Maybe with the Device Name which had requested this Blocks?)
More of a minor enhancement for a few cases. See my proposal in https://forum.syncthing.net/t/make-the-blue-progress-bar-logarithmic/2483
I would prefer, if it would display the full relative path. Right now only the filename is displayed.
the client does that already at runtime (Download/Upload rate) and that data could get saved into the config file for example every 5 minutes.