Thank you for your welcoming!

Actually, I’m very new in the world of tabbles, and I don’t use the software much (only 2 days at work, but had too little time to gain real experience). I breafly looked through the forum (god bless, it is small 😀 ) and had some ideas which I posted here.

After thinking next 5 minutes I’ve understood why hashing and indexing would blow the performance completely – just imagine, what time you need to generate the hash number for only one large sized file?.. Even worse – you need it to do with all the files from the storage when you will do reindex (relinking). So the idea is good only when the file has it’s hashsum at the OS/FS level, which is not implemented in windows FS, as far as I know.

One way to manage auto relinking – find the files by their unique properties – name, size, may be date and time of creation (I don’t know, whether it changing everytime or not… well, checked – all the dates are changing everytime 🙁 ), assuming that all the files are different, which in general is not an issue… Anyway, it will inflate DB again.

best wishes,
Rin.

"Andrea" wrote:
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 😆

"Andrea" wrote:
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 🙄

"Andrea" wrote:
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.

"Andrea" wrote:
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.

"Andrea" wrote:
Thanks a lot, we got that already!

Dobry vecher 😀

Andrea

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!