I'm not entirely sold on the complete abandonment of file names. Correct me if I'm wrong, but there are no file names in hydrus, everything must be a tag. Tags are for navigation, and file names can contain information that would just clutter my tag list with useless bloat. Example: MPCHC video snapshot creates a file with name "[filename][timestamp].png. The file name usually contains the episode name and number. There is no benefit to marking the episode name, number, and timestamp as tags, but this is also information I don't want to discard. If hydrus simply kept the file name… Also, the way you have hydrus store images sort of prevents operating on a picture library with external tools, such as a duplicate image scanner. Without human readable file names or a coherent, modifiable folder structure, I would have to export my entire database, delete all images in the database, do whatever needs to be done to the files, and re-import them. Why does hydrus simply not maintain a database of files as they are? Why must it completely take over, move and rename everything? It seems unnecessary and overbearing.
The internal image viewer navigates through pictures within the currently defined filter. If you open an image with an external viewer it will navigate effectively randomly; whatever pictures happen to be stored next to the one you initially viewed. Perhaps you could implement the option to hardlink all images in the currently defined filter to a temporary folder. External viewers would become more useable.
dev:
Filenames and location of files
Filenames in and of themselves can be cluttering, agreed, but by making pretty much everything a tag, you guarantee much easier forward compatibility. Using the "title:" namespace should do what you want.
The reason to "take over, move and rename everything" comes from its mobile nature. This is one area where I would like some more options though.
op:
Filenames & 'taking over' folders/files
I would be more amenable to the way things are currently done if I could automatically tag everything with a filename: and folder: namespace upon import and hide it from the 'tag selection' as per my other feature request. If done right, exports could restore the files and folders exactly as they were. While this is indeed possible to do at the moment, you have to manually define the regex/tag pattern every time you import or export- which brings me to a new feature request: import/export profiles. Save a predefined set of conditions for future imports and exports.
7f2c0e No.518:
If hydrus simply kept the file name…
I have a namespace called "filename" that I add to every file I import. If I ever want to get the original file back all I have to do is export it and use [filename]. This is the regex I use:
[^\\/:*?"<>|\r\n]+(?=..*$)
If you want to add it to files you've already imported, just import them again and it will tag their existing database entries.
Perhaps you could implement the option to hardlink all images in the currently defined filter to a temporary folder. External viewers would become more useable.
Oh I like this one, though I think read only symlinks would be safer. Otherwise it would be easy, create a folder named something meaningful from the search, and symlink every file into that folder.
7f2c0e No.520:
I have a namespace called "filename" that I add to every file I import
Yes, I saw the thread for "better regex" here, and I have been using the filename: where necessary, but it's a band-aid solution for a problem that hydrus goes out of its way to create! Hydrus hashes every image and renames the image files to their hash, correct? Then when importing a picture, if the file names match no duplicate is added. How about hydrus has the option to NOT move/rername files, and hashes are stored as a hidden tag (or otherwise in some form in the database)? This approach would actually be more efficient too, since it involves less read/write operations to the disk and relies on the database instead of the files. I get that you can live with tags and tags alone, but throwing out file names altogether is just needlessly limiting options.
Moreover the band-aid solution of creating a filename: tag doesn't address the issue that, once pictures are inside hydrus, access is relatively exclusive to hydrus, which is a problem. See next paragraph for an example.
just import them again and it will tag their existing database entries.
Yes, I have noticed this and I appreciate it deeply. I have made use of it several times already. However, if I'm exporting the entire database to perform operations on the files with some other program, the import will not work unless I delete the database first. Changed files will be seen as new files: duplicates everywhere. Deleted files will still exist in hydrus' database… Not starting from scratch would just be a mess. Using some other program to operate directly on the database images \could\ work if hydrus is smart about handling unexpected changes, but from that program there will no identifying information on the pictures; this would prevent me from making an informed decision for a process such as batch removing duplicate images. If two+ pictures are near identical, I'd prefer to remove the one with less/no tags, but I will have no way of knowing which picture that is. Similarly, if I ever want to open ANY picture with ANY program, I can't use file -> open in said program anymore- I'd need to open hydrus, export the picture, THEN open it with any given program. If hydrus allowed having coherent file names and structures, I could process my library so that tags are listed in the file name. Do this, and hydrus will go from being a roadblock, to a lubricant.
though I think read only symlinks would be safer.
symlinks require administrative powers under Windows, hardlinks do not, which is why I suggested hardlinks. If symlinks prove superior for whatever reason, then by all means it should be default in the linux version, and optional non-default for windows. I have to wonder how efficient the process of creating thousands of links is… we might run into a problem where it takes so long it just isn't feasible.
create a folder named something meaningful from the search
I was thinking that it would be linked to a system temp folder- no need for a meaningful name. If you want to save the folder for later you can rescue it from the temp folder manually, rename it to whatever you want. Well, hydrus could automate this process for you too, if the dev feels so inclined to write it.
7f2c0e No.528:
I don't mind that Hydrus renames and moves files into its own directory, but I would like an option to have the subdirs of client_files and client_thumbnails folders be stored as compressed archives (zips) instead of loose files. I currently store images this way and use a cbz reader to view them in order to reduce wear on hard drives. When you get larger collections (literally millions of tiny files) doing things this way almost becomes a necessity. Plus all that file slack adds up.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent
