Not requiring files to be readily available

[evinnichenko]

I am going to be "that guy" with awesome feature - but only as a rough idea.

Unless I am mistaken, TagStudio already supports all file types, even if not in preview (if not - hey, another feature). However, some people may have... slightly large collections spanning hundreds of GB that they store on external hard drives. Or they might try to use it for something large, like audio/video/3D models, which suffers the same fate of being stored on the external drive.

So, with the application already working via central database, why not add an option to reference files on currently unavailable drives, storing rough description and maybe a thumbnail for each of them? Then the main computer would only contain lightweight database and thumbnails, showing a "please connect [DRIVE_NAME]" every time there is an attempt to open the file.

This does suffer from potential for changes not getting reflected in TS (just as changing something while TS is off), but has potential to save a lot of space, and can be fixed with e.g. storing MD5 for each file and checking the files list (and searching) each time the drive is reconnected, even if it is a long process.

[Loran425]

Looks like there are 3 big topics here.

1. Allowing the data source to store information on directories that aren't currently available There has been a little discussion on the idea of separating the stored metadata from the actual entries and referencing either by hash #36 or by system metadata (*nix inodes/windows file handles) #197 most likely a combination of the two for the most robust rediscovery system. (windows volume id is part of the file handle so if you move from one volume to another the link would break) I believe something like this will likely come with the DB switch as its planned to eventually support multiple directories in a single library

2. Caching thumbnails so unconnected entries can still be displayed Definitely planned though I'm not sure the display of "missing" or rather "not currently available" entities was considered

3. Remote Libraries This is technically already possible (a library can be opened on a network device) but is intended to be supported further and the improved relinking/missing files avoidance mechanisms in 1 should make this less painful