Don't sync when device is on cellular/mobile connection

[dryo]

Tablets sometimes have mobile broadband onboard. The client should not sync over such connections or even better let the user define that.

IMO it would be best if the client asked upon detecting an unknown connection whether to automatically sync, not sync at all or ask every time for this network. This should be regardless of connection type (LAN, WiFi, Mobile, …) because some USB broadband devices emulate a LAN connection.

This would also solve #4309 and partially solve #1971

[danimo]

How would the client know that?

[stonerl]

Maybe, if possible only sync when connected to specific networks. I don't know whether or not this is doable.

On Android, the Podcatcher Antennapod has an option that let's the user specify the WiFi-Networks over which sync is allowed.

But to do such a check the ownCloud-client would have to know with which network it is connected. Is this even possible on OSX/Linux/Windows?

[jaykay2342]

On linux most distributions use the Network Manager. You can talk to it via a socket to know which connection is in use. Alternatively it would be nice if there is a way to do it the other way around. A interface (socket/cmd) i can talk to the ownCloud client to tell it to pause syncing, that would help to write a small plugin for the network manager to pause syncing when certain connections are in use.

[mikedolx]

This feature is for me more than an enhancement. I use a cellular modem in my laptop and due to the client i regulary wipe my data plan. This occurs very often to me. Of course, i regulary pause synching, but when I'm home i resume synching. Afterwards i forget it and my data plan is gone - its only 750MB.

I know at least in Windows 10 it is possible to define any network connection as "clocked" (thats the translation from german, i don't know how it's called on an english windows 10).

I wonder if the client could use this information and automatically pause synching when on a "clocked" network in windows 10.

[dragotin]

Utilizing this function https://msdn.microsoft.com/en-us/library/windows/desktop/aa384702(v=vs.85).aspx we could detect at least if we are connected via LAN. With that, we could have a checkbox

• Only sync when connected via LAN

however, we probably would like to include WLAN in that too, right? I wonder why the API does not allow that....

[mikedolx]

I use my laptop on ethernet when i'm home, so such kind of checkbox would be sufficient for me.

[pako81]

@pmaier1 00006690

[hodyroff]

@SamuAlfageme Please check for the API to be used on the Windows side for that. What about MAC?

[phil-davis]

In Windows10 you can set a network connection as "metered". Windows will use that setting to not download updates... over a "metered" connection. The selection choice is shown in the UI for WiFi and directly-mobile connections, but not for network devices that look like a wired LAN.
For wired-LAN-looking devices you have to make a registry setting, instructions here that have worked for me:
http://www.windowscentral.com/how-set-ethernet-connection-metered-windows-10
In my case, I had and old iPhone3GS that plugged directly into my laptop to give internet to the laptop, but of course that looked like a LAN to Windows10 and it downloaded a heap of stuff automagically, using up my mobile data quota.
It seems this feature was added in Windows8, so for Windows8 and above, it would be possible to check if the connection is marked as "metered". So would not work for Windows7.

[SamuAlfageme]

@hodyroff the support reference that @phil-davis links in his comment is a great place to start understanding the options that allow this behavior in Windows: it's a global OS option that wouldn't add logic to the client.

As for today; the convergence in Microsoft's OS (mobile and desktop) is making them the only folks offering these kind of options (Apple is almost always assuming his users on the move are working with iOS, which conveniently offers a comprehensive API for this).

There exist many apps designed to do this globally and establish some kind of while/black-list of apps that can access the network under some conditions. But they all still rely in the user input (selecting those networks/profiles and apps that are targeted). Some examples to see how they implement this behavior, are:

• Tripmode
• LittleSnitch
• Hands Off

Manually selecting networks that are known to be mobile/tethered is the most effective way to do this. It would be even possible to give the illusion of doing this automatically with some workarounds: e.g. switching between different OS X profiles and Firewall settings to limit the traffic of the application when connecting to specific networks, trying the low level path and detect tethering in the bottom layers of the packages (e.g. checking the manufacturer part of the MAC address, etc.). But all these options add complexity to the client while not being 100% reliable.

At the end of the day there must be always some kind of user input about which networks/SSIDs are cellular connections (or need to be seen as such).

[michaelstingl]

Using Tripmode would also be my recommended workaround. Works on Win and Mac and is only US$7.99.

[pmaier1]

For desktop we should suggest using a tool like @SamuAlfageme and @michaelstingl proposed since every other possibility will either require user input (which amounts to roughly the same as configuring such a tool) or won't be 100% reliable. Can we close here?

[sagamusix]

None of the suggested alternatives are free software or at least free (plus they require extra trust for doing questionable modifiactions to your operating system), and older Windows versions which are still supported do not have metered connections (but are aware of mobile broadband connections).

[hodyroff]

For me it sounds like the right approach is to do this outside of the ownCloud Desktop Client then. When users want to do this, its likely that oC is not the only application they should worry about. If there is currently no free tool, encouraging to develop one seems the best way, rather then try to put this into the ownCloud Client. We have plenty of corner cases to worry about first. We also have the "pause" as a workaround. If strong, new points come up, please don't hesitate to comment further.