C-Command Software Forum

Viewing multiple libraries via left pane (nested hierarchical list)

Hello - I am guessing there is no such feature as this yet. I am also supposing, it might not work with the way EagleFiler treats libraries, since then all libraries’ databases would be held open all the time. Still, if there was a way to drill down into libraries via the left hand bar, that would be great. I suppose the visualization of what one can do would be skewed, though - one would then expect that one is searching across multiple libraries, when one is not, etc.

I would just use one library but I want to be able to store vey large gigabyte+ files in one place locally, without having them being synced if I want to keep other stuff in iCloud or wherever. I’ll probaby just stick with one library for now. Is this anything that might change in Version 2.0, btw? I just bought into EagleFiler now, but would like to be sure my workflow isn’t a clash with anythingn coming up. :slight_smile:

This is a feature I’m considering for a future version (as mentioned here and in some other thread), though I can’t say at this point whether it will make it into EagleFiler 2.0.

For the specific case that you mention, it might help to name the folder of large files with .nosync at the end. That should prevent it from being uploaded to iCloud Drive.

Thanks @Michael_Tsai! I did see that one thread you mentioned.

I didn’t know that simply naming folders with “.nosync” would do that, I figured it had to be added manually (which would be a no-go) in some preference panel for each cloud service, or by adding some sort of “ignore” file to each directory. So, thank you for mentioning that!

I guess it’s still a bit limited in that it only works for iCloud. Although I could set up ignore filters in some other ways, most likely, for Dropbox or other such services.

My other idea is to use the application named Hook to use perma-links to the folder(s) of large media files that a particular project needs, and just store them in a text file or similar within the EagleFiler folder for that project.

I guess this is the great grey divide that encompasses information and file management vs. project and task management! I want one place to find everything for a “project”, but without duplicating large files to the cloud or even locally. Also, it might make sense to keep files related to one app in that app’s standard project directory. Some music editing software probably wouldn’t like it if I started moving the projects around, as it would then have to find all the “missing” files, if they were relative to another project, or a shared directory, etc. (although I usually set any options related to that to copy external files to within the specific project folder, so that can’t happen)

The other thing I was thinking, would be nice to encrypt old certain folders then, without encrypting everything. Maybe just bringing more of the benefits of multiple libraries into the realm of different folders within one library is what is needed! :slight_smile: Such as, allowing a symlink to a different directory, but making it APPEAR to be under the same folder in EagleFiler (could do this now via symlink, I guess - not sure what EagleFiler would do though). Same for encryption - if general system encryption isn’t enough, maybe allow it per-folder, in addition to per-library.

I guess I’m not sure what problem you are trying to solve here. There shouldn’t be much of a performance hit for using encryption, if that’s what you’re worried about.

Once folder is in EagleFiler, you can move it to another location and replace it with a symlink, and EagleFiler will follow that. Some cloud services don’t like symlinks, though. (One way around that is to put the actual folder in the cloud folder and the library and symlink elsewhere.)

Right, I wasn’t even planning on using the encryption feature, so I don’t know how it works - I thought it added another level of password protection… which I wouldn’t want on all files in my library. If it’s just lit-level encryption running behind the scenes, the way it can be enabled for the whole machine under MacOS, then I get your point, why would anyone not want it. (unless they want super easy recovery of some files without any keys - corner case though)

On the folder and symlink, that is good to know. Maybe, then - could EagleFiler have a way to create (or add) a folder outside its core directory for the library one is in, but do the work of symlinking it behind the scenes? Vs. having to use the terminal or command line. That would be nice! (and yes, that is a side benefit, for me anyway, if the cloud service ignores the symlinks - as long as it still syncs the symlink file, but doesn’t follow it to back up files on the other end, that is actually perfect for what I want to do - symlink to the data-heavy and very complicated project folders for the music/video/audio software - but don’t copy/sync it)

For example, if I have a 500 GB video shoot project file for Final Cut - I certainly don’t want that to be duplicated to EagleFiler, that needs to stay on the NAS where it is. I also would not expect “mobile access” to software-specific files like that. But I would like to be able to reference that directory and files within it easily within EagleFiler, mostly the project files themselves - for example, I might have project names like:

ProjectForClientA-imports.proj
ProjectForClientA-imports-4K.proj
ProjectForClientA_main_file_v0.1.proj
ProjectForClientA_main_file_v0.2.proj
ProjectForClientA_main_file_v0.3.proj
ProjectForClientA_main_file_v0.3-to_share_with_audio_guy.proj
ProjectForClientA_main_file_v0.4.proj
ProjectForClientA_main_file_v0.4-client-edits-1.proj
ProjectForClientA_main_file_v0.4-client-edits-2.proj
ProjectForClientA_main_file_v0.5-final-version.proj

Thise project files reference hundreds or thousands of other video and audio files within the same directory. I would just want to be able to tag and comment on those main files so I know where I am at across multiple such projects and be able to open them from within EagleFiler.

The whole library gets encrypted at the file system level (the library is on its own disk image), so you only have to unlock it once when opening the library.

This is planned for a future version.

Awesome! That will be cool when that’s added! And thanks for the explanation on the encryption scheme, that is pretty cool how it works, I had no idea. Makes sense to have a special library just for stuff that needs to be encrypted, in fact, now that I get how it works! And a big thanks for your help today on both of my threads, btw.