I don’t know if this is the right place for it. I thought about to post on GitHub Issue Tracker, but maybe it’s something which also concerns to common users, instead of just developers. And I don’t know how much of this is a problem to @kozec deal with on GTK. I’m sorry. I’m a designer, not a developer.
There’s some discussions about to selectively download the files in a folder. I think, specially considering the UX, that we could have a type of folder to just download placeholder files: on demand or on request folders. The files on this kind of folder should have faded icons. To try to open one of them triggers an event to download it. If some file disappears between scans, the placeholder appears again.
For this to work, we gonna need the GTK to add some things:
delete on all nodes command on context menu, if there isn’t any folder master node;
download or download and sync command, depending on having or not any folder master node, on context menu;
to register a file extension on Windows and MIME types on Linux and Mac;
Implemented this way, an advanced Syncthing feature will be easy to be used by common users and it will help to increase its usage (and also make me and a lot of already users happier).
I don’t know how much of @calmh’s work is need to do this. Maybe, it’s more a work for @kozec. I don’t know…
I think this requires a lot of OS specific magic, and not all OS’es we support even have the magic you are talking about.
If you are talking about pull files at the point they are touched.
You can already do selective sync by modifying .stignore, which works across all platforms.
OneDrive used to offer that, but currently I don’t think any existing syncing software provides this.
I’m not talking about touch the files. You’re right. Windows doesn’t even have an easy way to do this.
OneDrive allow us to make the files available online-only or available offline, but I have no idea on how they do that.
I’m talking about to associate a file type to Syncthing. I just took a look at the “other program” solution for this. For the new version, they created their own file extension, as I suspected. I signed for their beta testing, but… I give it up before even install it.
The .stignore files isn’t enough for what I’m asking. I’m talking about to be able to not download any file until need it.
And I am talking about ignoring everything, and excluding a file from the ignore list when you need it.
How is this not downloading any file until you need it?
I guess it would be easier to write a special new client to behave in this way oppose to adding it to syncthing.
I guess you potentially could implement this with syncthing-gtk (by controling .stignore), but the only feature missing in syncthing is getting the global list of paths so you could create these dummy files.
I’m not trying to ignore an already available feature, but to improve it. I don’t think the .stignore is easy enough to be used for everybody. e.g. how could I create a .stignore file before to download the folder?
I guess you’re right. All of this could be implemented on syncthing-GTK, including create the .stignore just after folder creation.
Besides to get he list of files, will be needed to know if there’s a master folder node.
Thanks for take the time to talk about this to me.
So for the newly added folder to start syncing, you will have to restart syncthing.
Before you restart syncthing, you can ignore the .stignore file.
The master folder is a setting of the individual, hence it’s not exported by any nodes, nor I think it should be.
You can always have an option to download or to download and sync, but whether other nodes accept the change you make is up for the nodes to decide, and your actions should not be influenced by that.
I don’t think it starts downloading at the point you accept the folder, as at the point you accept the folder the train has already left, and ClusterConfig messages which define who shares what have already been exchanged, hence you cannot hot add folders, and always need to restart.
Well, I’m not saying that it’s bad idea and I even believe what @robsonsobral says is pretty easy doable on UI side, if I understood him correctly. Only, but really big problem is that I’m don’t know any way how to query Syncthing daemon for list of ignored files - that is, for list of flies that daemon considered for downloading, but ignored as they matched one of .stignore rules. And there is big chance that Syncthing daemon doesn’t keep such list in memory ('cos for what reason would it?)
And, just fmi…
… which one is the other program you are talking about?
So there is an API for querying .stignores patterns, we could also make an API call which
outputs the directory tree, (ignored or not ignored, whatever is available globally, it’s just iterating over WithGlobalTruncated, fairly easy)
As for in memory, there is a regex matcher cache enabled by default, which holds all the files which were actually ignored, which we could also expose at minimal effort.
I feel that rewriting (or rather replacing) .stignores into selective sync (part of v1.0 milestone) will have a much nicer interface to it, which then syncthing-gtk will be able to interact with better, but feel free to hack something up now if you wish.
I guess the hardest part becomes the file manager integration, extension hooks (at least the way I see it)
I was talking about BitTorrent Sync. The version 2, which is on beta, uses files with the bts extension. However, the idea of having placeholder files is from SkyDrive, now OneDrive.
And how the placeholder for deleted files could be recreated? Or, better, how the GTK could know that there’s a missing placeholder file and recreate it?
Because, it a user doesn’t want the file on his machine anymore, he or she will delete it, what not mean it should be deleted from the other nodes.
Well you see what placeholders you have versus what is available in the global index.
I don’t expect to have placeholders for files that have actually been removed from the global index.
Furthermore, don’t get too excited though, the fact that we are discussing this means very little
[quote=“robsonsobral, post:15, topic:1779”]
Because, it a user doesn’t want the file on his machine anymore, he or she will delete it, what not mean it should be deleted from the other nodes.
[/quote]Pattern for placeholder filetype would be needed in .stignore, otherwise they’d get synced everywhere and start causing mess in general. That’s not a problem. But there is no… ahem… sane way how to tell that user deleted placeholder (and it’s not missing because there is new folder created in cluster), so with implementation that I’m imagining now, it’d be recreated shortly.
By the way, just to check if I understood what you want; What could be done:
New checkbox in ST-GTK repo edit dialog, saying something like enable placeholders for this directory
Enabling this would modify .stingore to ignore everything, what’s not already synchronized
On every index update would ST-GTK query Syncthing daemon for list of ignored files <-- this is part that probably needs to be implemented in Syncthing first
Upon receiving this list, ST-GTK would create files in FolderName.stplaceholder style for every ignored directory
And at last, *.stplaceholder would be registered to be opened by ST-GTK, so when user doubleclicks placeholder folder icon, he will be prompted by question if he wants to download real folder.
As I said, I’m not sure if this is most useful feature to add, but it really sounds pretty easy to implement on ST-GTK side. I’m not sure about daemon though.
I’d rather export ALL the files that syncthing is aware off, and we already export regexp patterns as part of /rest/ignores, which you can then use to work out what’s ignored and what’s not from the global model.
