Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for syncing ownership of files #1329

Closed
crosbymichael opened this issue Feb 5, 2015 · 71 comments
Closed

Add support for syncing ownership of files #1329

crosbymichael opened this issue Feb 5, 2015 · 71 comments
Labels
enhancement New features or improvements of some kind, as opposed to a problem (bug) frozen-due-to-age Issues closed and untouched for a long time, together with being locked for discussion
Milestone

Comments

@crosbymichael
Copy link

crosbymichael commented Feb 5, 2015

It would be nice to add support for syncing file ownership with uid and gid. This already supports permissions.


2019 note: this issue was originally titled "...syncing uid:gid of files" and there's initial discussion of that, but that's too constricted hence I've retitled it. //@calmh

@kozec
Copy link
Contributor

kozec commented Feb 5, 2015

Wouldn't that require running Syncthing as root?

@jpjp
Copy link
Contributor

jpjp commented Feb 5, 2015

Yep that would require root.

@AudriusButkevicius
Copy link
Member

I am pretty sure this is unlikely to happen as uids:gids can make no sense on windows or on a device which doesn't support users (android) or even have them.

@AudriusButkevicius
Copy link
Member

You can solve the same problem by running multiple instances though.

@facastagnini
Copy link
Contributor

I am syncing the /Users directory between two mac, so I run syncthing as
root. It runs great.

I run into the annoyance of having uid out of sync a few times.

As a reference, I use crashplan for backups. They preserve the uid:gid
metadata and they do their best effort to preserve this attributes if you
restore on a different platform.

So adding this values to the syncthing db and trying to apply if the OS is
homogeneous is doable.

Unfortunately I am not a programmer, so I can't contribute a patch, but I
think many people will greatly appreciate this feature.
On Feb 5, 2015 3:25 AM, "Audrius Butkevicius" notifications@github.com
wrote:

You can solve the same problem by running multiple instances though.


Reply to this email directly or view it on GitHub
#1329 (comment)
.

@crosbymichael
Copy link
Author

@AudriusButkevicius I don't think windows or android is a good reason not to support this. This is the same idea as mtime and permissions.

It would not matter if this is the default or not but a configurable option to support this would go along way for use cases when using this as a deployment and configuration system for servers and not just desktop use.

@api984
Copy link

api984 commented Feb 5, 2015

if you sync between 2 linux servers or more with SAMBA on top can UID and GID be synched then?
this would solve my problem because all samba instances would have same UID and GID on all locations for me for an example. if both systems are same linux then file ownership should be synched at least....
if same but it should note that same UID and GID should be on both sides the same maybe?
#id testuser
uid 1000 gid 1000 on both locations....
one could have 1000 and the other 501 ... which are not same user....

@AudriusButkevicius
Copy link
Member

@crosbymichael feel free to make a pull request.
Given it's implemented sensibly, I am pretty sure @calmh will consider merging it.

Saying Windows and Android is not a good reason not to support is not true (at least what I believe in).
Turning the code into an unmanageable mess just for the sake of it working on Unix, is a good enough reason for me. I just sadly cannot comprehend a sensible solution which works across the board.

By the end of the day, we (or perhaps that is just my personal view) are trying to make a tool which works on multiple platforms, and we try to make sure that all features work on all platforms (more or less).

I guess you could do uid:gid mapping based on the user account names across Unix and Windows, but then perhaps Unix people would expect it to work based on integers... Atleast that is the sort of behaviour I would expect syncing stuff from Unix to Windows... Not sure... gids don't even make sense on Windows.

@crosbymichael
Copy link
Author

@AudriusButkevicius lets try to keep the discussion professional and not suggest that someone's contribution for a feature that they care about would be "Turning the code into an unmanageable mess just for the sake of it working on Unix"

@AudriusButkevicius
Copy link
Member

I am not saying that.

What I am saying, is that the only solution which comes to my mind now, would make an unmanageable mess. I guess I am a bit of an advocate of Windows here, and I don't want Windows to be left out, hence why it would be a mess.

As I said, given it's done sensibly, I am sure it could become a feature, even if an optional one.

@crosbymichael
Copy link
Author

Ok thanks. I opened this issue first instead of a PR so that this could be discussed with the maintainers. I know what it's like to have feature requests implemented in a PR without any discussion.

I'm more than happy to look for an elegant solution for this. If it turns out to add more complexity than what it would be worth, then I have no problem closing this issue.

@AudriusButkevicius
Copy link
Member

The boss is back in a few days, hence you can perhaps propose a potential solution to the problem which then could be discussed.

There is some history of this available here (which might have some sensible ideas):
https://discourse.syncthing.net/t/sync-file-ownership-and-permissions/143

Though I feel you cannot get a way with some sort of optional remapping config

@AudriusButkevicius AudriusButkevicius added enhancement New features or improvements of some kind, as opposed to a problem (bug) help-wanted labels Feb 5, 2015
@calmh
Copy link
Member

calmh commented Feb 9, 2015

Yeah, the relevant discussion is linked above. Solving this as described above (just copy uid+gid) isn't rocket science. Unfortunately it's also a half baked solution, as it doesn't work on non-Unixy systems, and will anyway not solve the other aspects that will pop up if this is implemented (sync by username and not uid, map some uids to others, etc)... As such, it would need to be really neat and unobtrusive to be worth it, in my opinion.

@MurzNN
Copy link

MurzNN commented May 13, 2015

Solving this issue via copy uid+gid is good step and already will be usable via most wanted users on system with mutual user list (for example, ldap database or active directory). But in other cases uid for same user on different machines may be different, so when we sync numeric uid - on one computer user with uid 1002 may be Bob, on second - Peter.
So better solution is sync user login (name) and group name. They can be same on different systems (Linux, Windows, Mac) and this way of sync will work on mixed sync process.

@syncthing syncthing locked and limited conversation to collaborators Oct 16, 2015
@calmh calmh modified the milestone: Unplanned Jan 1, 2016
@calmh calmh removed the help-wanted label Jan 1, 2016
@syncthing syncthing deleted a comment from bear0330 Nov 8, 2017
@syncthing syncthing deleted a comment from johntdyer Nov 8, 2017
@syncthing syncthing unlocked this conversation Nov 8, 2017
@incansvl
Copy link

incansvl commented Nov 8, 2017

I appreciate this is a complex area. It's challenging even to work out what the best approach is, before you try and implement it. However- It's been done before, by Samba. In fact Samba goes way beyond the simple case to deal with ID mapping across LDAP domains etc., which is hopefully beyond what most syncthing users would need.

It would seem sensible to look at some reduced subset of what Samba can do as an initial design goal,

The benefits would be significant-

  1. Sync files for mutiple users beween 2 or more machines with a single shared installation and config on each machine.
  2. Maintain (or at least do minimum, controllable damage to) file ownership, permissions, creation times stamps etc., especially if files are replicated across to a machine and then "round tripped" back again to the source machine for any reason.

@calmh
Copy link
Member

calmh commented Nov 8, 2017

I think that in order for anything to happen in this area someone needs to step up with (first) a design proposal of what the relevant subset is, detailing which situations it handles and which situations it does not, and (second) an actual implementation of that proposal. The person taking on that challenge should certainly look at prior art in the area and count on this being a several months long project to drive home.

I don't think it's helpful, in itself, to note that there are solutions that solve a different but similar problem after probably hundreds of person hours of development. That's clearly the case, but it doesn't move this issue forward. It's also self evident that there would be benefits to syncing ownership and advanced permissions.

@Ferroin
Copy link

Ferroin commented Nov 8, 2017

If this gets implemented, it should ideally provide some means of mapping ID's and names. People don't use the same user name everywhere (especially if they've got different operating systems involved), and there are cases where neither syncing based on numeric ID or based on name will work correctly (in fact, by numeric ID won't work most of the time when multiple users are involved, and is pretty much guaranteed not to work if syncing between multiple operating systems).

@illwieckz
Copy link

illwieckz commented Jan 15, 2018

It's not syncthing's task to do uid/gid name mapping, there is efficient robust dedicated tools to do that out there (like idmap itself) and it's a required service of any correctly designed domain to provide consistent uid/gid mapping. For example a samba-based domain can provide consistent uid/gid numbers based on ldap's sid accross all servers joined to the domain. If not, it means the network is misconfigured and it's not syncthing's fault.

Providing uid/gid support is only making syncthing able to take care of two metadata numbers, no less no more.

If someone have [ug]id↔name mapping problem it's a problem in his setup, it's not a syncthing problem. And I don't expect syncthing to be able to workaround user's misconfiguration problems (and please don't implement such things !).

Tools like rsync or unison just take care of uid/gid number, it's up to the sysadmin to install an id mapping service, and syncthing does not have to do more (and please do not do more than just replicating the uid/gid numbers).

I see this issue is open since almost three years now, it looks like the only real blocker is the fact the thread derivated from the very simple "syncthing needs uid/gid replication" topic (which is not much complex than permission or mtime replication) to the very complex "syncthing must be an id mapping service" topic.

Let's not expect syncthing to do things it's not up to syncthing to do or uid/gid replication will never be there…

@MurzNN
Copy link

MurzNN commented Jan 16, 2018

In this issue - users want to sync files with different owners, so syncthing need to have solution for this needs - keep and sync file owners (no matter what way: uid/gid, or username, group, acl, other ways), not only file permissions.
This will be very useful when you sync via syncthing as root, for example, whole /home folder, as multi-target alternative of rsync tool. This way will be much easier instead of running separate syncthing daemon for each user.

@AudriusButkevicius
Copy link
Member

I think it's a sensible feature to have, but as I said earlier I think it's a can of worms in terms of implementation, because some people will want to sync based on account/group names, some will want based on uid/guid, I think windows only has names.

So I think the first step of this would be to write an implementation proposal of how all of these pain points would be addressed.
Once we are happy with how the proposed implementation would work and what it would deliver, then I think we'd be happy to accept a PR.

Also, just to note, this has moved on a bit since some of the last posts. There is now an advanced feature flag which copies the ownership from the directory the file is being created in, which might be sufficient. This obviously requires special capabilities/root.

@aawsome
Copy link

aawsome commented Apr 13, 2020

All right, I'll start preparing a proposal 👍

My thoughts about the pain points are as follows:

  • Each client needs to define a mapping from local user/group to the global uid/gid and another mapping from global uid/gid to local user/group (for each synthing folder). The local user/group can be (depending on the OS) the POSIX uid/gid, a string or whatever is needed for this specific OS.
  • The mapping from local user/group is defined by a given mapping table. If a local entry is not in the mapping table, make an option to either map to a (given) constant ID or (on POSIX clients) map the global ID to the identical local ID. Default (and current behavior) would be an empty mapping table and mapping to the constant ID 0.
  • The mapping to the local user/group is defined by the same mapping table as above. If a local entry is not in the mapping table, make an option to either map to a (given) constant user/group or (on POSIX clients) map the global ID to the identical local ID. Default (and current behavior) would be an empty mapping table and mapping to the user that executed syncthing.
  • Filling the mapping table is a GUI topic. I'm thinking about a possibility to import csv or JSON files..

I hope that this should cover the pain points - I there something I missed?

@AudriusButkevicius
Copy link
Member

AudriusButkevicius commented Apr 13, 2020

I think it's best if you start a forum thread. Because you'll hear tons of opinions here with objections, demands and what not here, so I'd rather keep that to the minimum.

@illwieckz
Copy link

illwieckz commented Apr 14, 2020

@aawsome there is two feature requests that are messing up in that whole thread:

  1. Implementing uid/gid sync, i.e. syncing of uid and gid integers. No more. Users would have to rely on third party id mapping like Winbind. It would be cool to extend the syncing to ACL too. That was the initial, simple, feature request. We all know this would not be useful for everyone, but that's a requirement for 2. anyway.

  2. Implementing a complete alternative of Winbind or other id mapping architecture to be shipped within Syncthing, so users of 1. would not have to rely on third party tools. This second feature request requires 1. to be implemented first.

This second feature request, which is legit but can be done as a second step, requires a far much amount of work. Sadly, this second feature request added so much noise to this thread it entirely took over this thread.

So, five years later 1. is not implemented because of 2, but 2. requires 1. to be implemented first. That's part of why the thread is stalled.

While I fully understand why feature request 2 would be very cool and I may use it myself (I know how hard it is to get a complete setup like the one using Winbind), it's possible to wait for 2. to be implemented after 1. is implemented, by relying on existing third-party id mapping tools. In any way, 1. is required for 2.

I attempted to separate the issues again and created #6105 to track feature request 1. while this one would be for feature request 2, in an attempt to unblock the situation. I'm not sure the feature request 2. is going somewhere before 1. is fixed. It would probably better to reopen #6105 before spending time on this one if you worry about this one to be still open in the next five years.


Edit: I forgot there is a third feature request messing with this thread:

  1. The need for a name translation infrastructure, for when user names and group names differ and tools like Winbind or feature 2. can't do the job. But that would make sense to implement 1. then 2. then 3.

@AudriusButkevicius
Copy link
Member

I don't think just option 1 would ever be accepted, because it works on one platform only, which is a no-go for a cross platform tool.

@darkpixel
Copy link

@AudriusButkevicius That's not correct. All my Linux boxes have Samba and Winbind installed...so even if I were syncing between a Windows box and a Linux box, all domain accounts are available in both places. But at least in my case I'm syncing between ~24 Linux boxes which all have the same account information available.

I see two systems that can be implemented.

The first is implementing ownership/group info. IIRC Windows doesn't have the concept of file ownership--just permissions. This would cover Linux-like systems.

  1. An option to sync/not sync file ownership info.
  2. If ownership syncing is enabled, have the option to strictly sync based on the underlying user ID or SID (Linux uses UID, Windows uses SID) meaning account identifiers must be the same on both ends. This would be useful for domain-joined systems or Linux boxes that have winbind or synced /etc/passwd files.
  3. Have another option to strictly sync based on the user name lookup. i.e. if a file on one box gives 'aaron' permissions, ignore the UID/SID and look up 'aaron' on the target box and give it the same ownership.
  4. Have some sort of translation map:
    'aaron': 'asmith'
    'joe': 'jjohnson'
    etc...

The second would deal with permissions.

Similar to the first system, permission options could be something along the lines of "don't sync", "sync by UID/GID/SID", "sync by name", and "override user/group"

In my case I would choose to sync ownership and permissions either by UID/GID/SID or by lookup.

A bit of pseudo code:

if folder.sync_ownership == "disabled":
  # Do nothing

elif folder.sync_ownership == "by-id":
  set_owner_group(incoming_file_path, incoming_file_owner_uid, incoming_file_gid)

elif folder.sync_ownership == "by-lookup":
  user = lookup_uid_by_name(incoming_file_owner_name)
  group = lookup_gid_by_name(incoming_file_group_name)
  if user is None or group is None:
    # Ignore it?  Maybe an option to sync unknown users/groups to a specific user/group?
    # Maybe log the path to the file, and what user/group couldn't be resolved for easier troubleshooting
  else:
    set_owner_group(incoming_file_path, user, group)

Permissions could follow a similar format.
Attempt to resolve the names or uid/gid and have a mapping for compatibility between different operating systems. i.e. read/write/execute on a folder in Linux gets converted into 'full control' on Windows. read/execute gets converted to read/list folder contents (or something like that).

If Linux has extended ACL support enabled, have an option to sync the extended ACLs instead of the standard ACLs.

Just a thought.

@AudriusButkevicius
Copy link
Member

"That is not correct. All my Linux boxes have Samba and Winbind installed"

This is "not correct" only in your local context. I don't think every Linux machine ever has winbind installed and pre-configured waiting for syncthing to do it's thing. Also, winbind means nothing on Windows.

I don't think your comment disagrees with what needs doing, the actual implementation details may vary hence I am not going into details.

I am mostly arguing that whatever implementation lands, it should land with ability to remap/lookup/whatever you want to call it stuff straight away, not to deprive/hinder clusters with mixed operating systems.

@darkpixel
Copy link

Sure.

What's the use case for "I want permissions synced" along with "...but the user accounts aren't the same on both (or all) machines"?

If I want to sync with some internet rando with permissions (and/or ownership) to another internet rando...but they don't have accounts that are in sync? I just can't see that use-case. If I were syncing family photos to my mom's computer, I don't care about permissions or ownership on the files. If I'm distributing media files or a podcast, I don't care about permissions.

But if I'm in a corporate environment where permissions matter, I already have the infrastructure set up to ensure usernames and passwords exist on the boxes....or why would I need syncing in the first place? In my case, my Linux boxes are DFS targets, as well as folder redirection targets for user profiles...so they already communicate with active directory.

Maybe on a home network where one machine has 'owner' and the other machine has 'aaron'? A simple mapping would handle that...either a list of users to map to other users, or simply "map all permissions to "aaron"....but I think that's a rare case as opposed to just letting syncthing run as "aaron" and sync while ignoring permissions.

Maybe I'm missing something?

@AudriusButkevicius
Copy link
Member

You are looking at it through a corporate prism, which is probably a minority of our users, hence I don't think we explicitly try to cater for them, but try to cater for the little guy, and I think the little guy will need this.

You yourself pointed out a case in a home network.
There are tons of other cases, such as accounts that were created before "oh I should make sure the uid's or the names match".
People don't run ADs in their house. I want to be able to map uid 1000 to my name on windows, and uid 1001 to my sons account in Windows. My uid on my mac and my linux box might not match up.

There are various appliances (synology comes to mind), that run an app under user X, but requires the files to be owned by user Y for some other app on the appliacne to be able to read/use those files. Stuff inside of docker containers falls under this as well I think.

Nobody is saying that we need complicated mappings, it would simple mappings as you yourself pointed out.

I am just saying that "just syncs uids, one to one with no remappings" as someone proposed above, is not good enough.

@darkpixel
Copy link

You are looking at it through a corporate prism, which is probably a minority of our users, hence I don't think we explicitly try to cater for them, but try to cater for the little guy, and I think the little guy will need this.

I pointed out a home network case and showed that users probably wouldn't make use of the feature. What home would:

  1. set up some sort of authentication system beyond what's on the local Windows box for home users
  2. Not set up a domain
  3. Manually keep those users in sync and expect permissions to sync

Probably a lot less than the 'minority' of corporate users you are talking about.

Most home users just want files synced and working (like syncthing already does now).

Permissions are almost exclusively a corporate or power-user thing.

People don't run ADs in their house. I want to be able to map uid 1000 to my name on windows, and uid 1001 to my sons account in Windows. My uid on my mac and my linux box might not match up.

Sure--so two ways to do that in this hypothetical situation:

  1. Make sure your usernames are consistent across the boxes and syncthing could resolve names to IDs.
  2. Set up a mapping. (mac aaron) <-> (windows aaroniscool)

But like I said, I doubt that's the majority. How many home users want to do weird permission mapping stuff? I'd bet a majority of corporate users want to handle permissions. In fact, that's why we still use Windows DFSR and other hacky solutions in our corporate environment instead of syncthing. Syncthing only manages stuff where I don't care about permissions--like globally accessible folders where everyone has full control or globally accessible folders where everyone gets read-only access.

I am just saying that "just syncs uids, one to one with no remappings" as someone proposed above, is not good enough.

I agree. Maybe boil it down to four 'permission options' for a folder:

  1. do nothing (current and default behavior)
  2. sync IDs (syncs based on raw UID/GUID/SID/wahtever)
  3. sync names (look up 'aaron' on one box, find 'aaron' on the other box) with an option for what to do when a user isn't found (use default permissions, or use the syncthing user)
  4. map names (provide a list of 'remote' IDs and what 'local' ID it gets mapped to possibly with a special mapping for "remote ID isn't listed" gets mapped to a specific local ID or the syncthing user)

@AudriusButkevicius
Copy link
Member

AudriusButkevicius commented Jun 16, 2020

The reason this is issue exists is not because there fundamental disagreement of what needs to be done here
I think (and I might be wrong here) the maintainers agree on the scope of work here.

The reason this is open is because nobody needs this badly enough to work on it.

There were a number of suggestions to reduce the scope "just to get something out the door", which as you say, would only be useful to people running ADs, which I am personally against, because it leaves other platforms (thinking about the specific proposal) and the little guys deprived.

@darkpixel
Copy link

Agreed, however starting simple to "just get something out the door" to support the (probably) biggest use-case (permissions sync in a corp environment) wouldn't "leave other platforms deprived".

You already don't have it. You're already deprived. ;)

The reason this is open is because nobody needs this badly enough to work on it.

I'd totally dive in and work on it....if Syncthing were written in Python or nodejs...Go has been on my bucket list for a while, but I just haven't had the time...

@AudriusButkevicius
Copy link
Member

AudriusButkevicius commented Jun 16, 2020

If corporations need it, they can go and sponsor someone to work on this., yet I'd expect the full implementation.

@darkpixel
Copy link

Who can I sponsor and how much do they need?

@AudriusButkevicius
Copy link
Member

kastelo.net I guess is the official "commercial" body behind syncthing, but I guess you can hire someone who knows a bit of Go and html to do this.

@aawsome
Copy link

aawsome commented Jun 17, 2020

The reason this is open is because nobody needs this badly enough to work on it.

Maybe I can tell about my story: I started implementing it (just minor change when syncing just uid and gid 1:1 and also with option to sync/not sync ownership). This however needed a DB schema update and also a rescan of all folders on all devices to update the DB.

So I tested it and used it on my devices (all linux, all identical uid/gid) - works like a charm!

Then I thought about the next steps to create a PR:

  • think about mapping
  • owners in Windows -> ugly!
  • how to make a database migration -> ugly!
  • change the Web-UI to let the users enter mappings, etc.
  • what to do if only ownership of a file is changed??

So, finally I left with just using my patched version which is still working like a charm.. 😉

Maybe if I find more time, I'll tackle the above mentioned points and prepare a PR.

Or, if wished, I can simply share my modifications, maybe it is enough to opt in/opt out and someone can tackle the DB migration topic such that we'll only get an optional ownership syncing that only works for linux but doesn't harm anything on Windows.

@darkpixel
Copy link

@aawsome I'd love to get a copy of the patch and buy you a beer or something from an Amazon wishlist... I only need 1:1 uid/gid mapping on Linux since all my NAS boxen have identical IDs through winbind.

Or if you want to try getting a PR submitted or something, I might be able to do some sort of sponsorship through my company or one of my clients that needs it.

@hiveai
Copy link

hiveai commented Aug 29, 2020

@aawsome Could I get a copy of your changes please? I have 2 linux boxes I'd like to sync. I would value what you have even if the corner cases you outlined have not been addresses. Cheers!
@darkpixel Did you ever get a copy of the uid/gid syncing patch? If so, could I get a copy?

@Striffly
Copy link

You can find the patch here : https://github.com/aawsome/syncthing/tree/sync-owner
I will soon test it on a linux multi-device configuration (if I reach the end of a custom build on docker), I will keep you informed!

@aawsome
Copy link

aawsome commented Nov 25, 2020

Sorry for not answering. This is the patch I'm still using, however it is based on syncthing 1.5.0 and there have been quite some changes in the master code since then.
I wanted to have a look how to rebase my patch but so far I didn't find the time for it. (and, honestly, after some time forgot about this topic).
Appreciate any help with rebasing this!

@calmh calmh closed this as completed in adce6fa Jul 26, 2022
calmh added a commit to calmh/syncthing that referenced this issue Jul 26, 2022
* main:
  all: Support syncing ownership (fixes syncthing#1329) (syncthing#8434)
  gui, man, authors: Update docs, translations, and contributors
@calmh calmh added this to the v1.21.0 milestone Jul 26, 2022
calmh added a commit to calmh/syncthing that referenced this issue Jul 28, 2022
* main:
  cmd/syncthing, lib/config: Remove restartOnWakeup option & functionality (fixes syncthing#8448) (syncthing#8449)
  gui: Remove blank meta tags (syncthing#8362)
  gui: Add device sync status (fixes syncthing#7981) (syncthing#8401)
  gui: Fix detailed staggered versioning information in folder info (ref syncthing#8348) (syncthing#8433)
  all: Support syncing ownership (fixes syncthing#1329) (syncthing#8434)
  gui, man, authors: Update docs, translations, and contributors
  lib/model, lib/config: Apply sensible defaults for auto-accepted encrypted folder (fixes syncthing#8296) (syncthing#8427)
  gui: Move filesystem watcher explanation from tooltip to help block (syncthing#8432)
  gui: Use discovered IDs from cache when adding a new remote device (syncthing#8382)
  build: Update goleveldb (syncthing#8440)
  gui, man, authors: Update docs, translations, and contributors
  cmd/syncthing/cli: Add show discovery command (fixes syncthing#8007) (syncthing#8378)
  gui, man, authors: Update docs, translations, and contributors
  lib/osutil: Only announce address of interfaces which are up (fixes syncthing#7458) (syncthing#8422)
  gui: Fix missing span end tag and missing nbsp semicolon in HTML (syncthing#8419)
Martchus pushed a commit to Martchus/syncthing that referenced this issue Aug 4, 2022
This adds support for syncing ownership on Unixes and on Windows. The
scanner always picks up ownership information, but it is not applied
unless the new folder option "Sync Ownership" is set.

Ownership data is stored in a new FileInfo field called "platform data". This
is intended to hold further platform-specific data in the future
(specifically, extended attributes), which is why the whole design is a
bit overkill for just ownership.
SimonPickup added a commit to MobiusSync/syncthing that referenced this issue Sep 17, 2022
v1.21.0

Bugfixes:

- syncthing#8219: REST API: db/completion no output when one folder is paused
- syncthing#8479: Panic in failure reporting

Enhancements:

- syncthing#1329: Add support for syncing ownership of files
- syncthing#7981: Show likely status of disconnected devices
- syncthing#8296: Auto-accepted receive-encrypted folders should have more sensible defaults
- syncthing#8323: Show internally used paths in the GUI for debugging
- syncthing#8448: Remove "restart on wakeup" functionality
@st-review st-review added the frozen-due-to-age Issues closed and untouched for a long time, together with being locked for discussion label Jul 26, 2023
@syncthing syncthing locked and limited conversation to collaborators Jul 26, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New features or improvements of some kind, as opposed to a problem (bug) frozen-due-to-age Issues closed and untouched for a long time, together with being locked for discussion
Projects
None yet
Development

No branches or pull requests