I think it'll be much easier for user to just have 2 separate panel, one for displaying all the jobs, one for jobs that will run when execute the script. Then user can just drag and drop or click a button to add the jobs to the script.
Right now, you have to write the script by hand, which is tedious and error prone (typo etc.)
How about it?
PS: One a side note, can you explain how "Short comparison" work compare to "Full comparison"? I noticed that "Short comparison" is much faster than full, but I don't know about its correctness.
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on Facebook
Follow us on LinkedIn
Follow us on Twitter
Follow us on Mastodon
Follow us on BlueSky
the ease of use of the scripting tab is planned for the next version of Toucan, see my post about it here which I will expand more when I start to work on that particular feature.
A set of good, useful example scripts would go a long way towards showing people how to set up a script, and also what they can be good for.
At the moment I'm not even clear what I could do with a script or why I'd want one.
you are right, there are a couple in the helpfile at the moment but I hope to add more for the 3.1 release. Basically a script allows you to perform more complex operations than are allowed by default, for example running three syncs one after the other, or running a sync on weekdays and a backup at weekends.
So it'll still be an editor? why not make it drap-and-drop?
BTW, thanks for making Toucan.
will hopefully be a little more like a proper code editor. I am not sure what you mean by making it drag and drop though, do you have an example as to what you would like to be able to drag and drop?
Short comparison creates a checksum from only a few bytes of a file, whereas full comparison creates a checksum/hash of the entire file. Obviously the latter takes longer since it has to read the entire file in order to create the hash. Short comparison should be good enough in most "average" cases.
Hmm, so short comparison will check for like a few beginning bytes of the file? That doesn't feel very reliable. What if I change the content at middle of a text file?
if you are using anything compressed, e.g. a docx file then because they normally store a hash in the header you will be fine.
Just to be exact Toucan reads 1024 bytes from the start and the end of the file to try and maximise it's chances of finding such a header. Also if you change the contents in the middle of a file and this changes the files overall length, even by just a byte then it will be flagged up as different. The only case where it will fail to flag a difference is if you change a few characters in the middle of a file which don't change its length or any sort of header, for example the middle of a txt file. In this case the only way of ever finding the change would be to read the whole thing, so if you think this is a frequent occurrence in your workload then a full check is probably the best thing to do.
Personally I would suggest that doing a modified time check and a short check should catch virtually everything, but I don't have any hard numbers to back that claim up.