Home › Forums › Feature requests › and quot;Collect all the hashed files again and quot; feature › Reply To: Re: and quot;Collect all the hashed files again and quot; feature
usually we try not to be too rude here, but since it’s Friday night and some of us have been drinking beer, it may well happen that we burp at some point
I see 😆
Well let’s pinpoint a couple of thing: having exactly the same structure and almost the same structure makes a huge difference, since almost the same structure would imply that some sort of AI must understand what fits and what doesn’t… and this is science-fiction 🙂
Maybe I couldn’t understand you, but I don’t wish to imply any of AI at all. Assuming you have not only the file URI stored in your DB, but also the unique hash (i.e. MD5), you can scan through all the locations within the predefined area and get the files with the same hash and link them. This process does involve only the hash calculation and comparison of it with the values in DB. This should be rather long process, but if I don’t want to make it all the time, I can wait sometimes.
Well, maybe it will be used only one or two times per user 😆 Well, but now you got the idea clearly I guess 🙄
2) syncronization function: this has not even been discussed yet… maybe it will happen but it won’t be soon.
You can implement a kind of brutforce synchronization 😀 Analyze in a previous manner the structure of the first storage and make the same structure on the second, making only new folders and using the files already present on the second drive. All the files which are not in the same set are ignored and untouched.
3) a quick and rough solution, if you have exactly the same disk structure on both computers (e.g.: on both you have all the files stored in C: and then you manually copy all the folders that need to be mirrored and place them in a mirrored position ) could be to simply manually copy the tabbles database from one pc to another, time to time. Your tabbles database is in C:Documents and Settingsyour_user_nameDocumentsTabblesDatabasescur_db.tabblesdb. Not very efficient but it works! 😉
This is the thing I wanted to avoid – to have the same structure.
Thanks a lot, we got that already!
Dobry vecher 😀
Vecher dobry, but it’s late night now anyway 😀
Well, I will wait for the nested tabbles.
Oh! Just a little idea – to have predefined Tabble Types: Data (dd/mm/yyyy), Volume N, Issue M – where you should only fill the gaps when tabbling. For example if I want to organize my collection of science articles (this is exactly what I’m trying to do) I also want to set the data of the issue, volume number and issue number – it is enough to make some sortings and selections. BUT also must be the feature to combine those tabbles by selecting the range of numbers (a kind of temporary tabbles, for example – "Volume 10-15" + "Data 10/04/1985-10/02/2000"). I think adding some wildcarding to the combining of tabbles will be very useful. Well… To involve the feature of enumerated tabbles!! This includes all the cases I’ve described before.
Bye for now!