darktable icon indicating copy to clipboard operation
darktable copied to clipboard

Relative file and folder paths - a simple solution

Open titan3025 opened this issue 1 year ago • 10 comments

Is your feature request related to a problem? Please describe.

The problem is that if I want to store my photos on a network drive or an external disk and connect to the photos from different machines with different operating systems darktable wont be able to find the photos since the paths in the library.db are absolute file paths.

Describe the solution you'd like

The solution I would like is similar to the catalog system in Lightroom where if someone chooses to store the photos in a folder that is in the same place as the catalog (library.db in darkroom's case) the photos will always be adressed relative to where the catalog is. In the case of darkroom I would store the library.db also on the external or network drive and darkroom would store the locations of the photos and folders relative to the location where library.db is. Like this there would no GUI changes. Darkroom would simply import photos relative to library.db if the photos are in the same folder als library.db. A quick note in the manual suffices (for now).

Alternatives

Additional context

titan3025 avatar Oct 14 '24 11:10 titan3025

This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

github-actions[bot] avatar Dec 16 '24 00:12 github-actions[bot]

I saw that the ticket was marked as stale, due to inactivity.

@ralfbrown did you have a chance to look into this?

titan3025 avatar Dec 16 '24 07:12 titan3025

No, and I never indicated that I would - I just categorized the issue.

The default location for library.db is a hidden directory and few users override that (since it requires commandline arguments), so I suspect that nobody else has responded since it's a fair amount of work for relatively little benefit.

ralfbrown avatar Dec 16 '24 07:12 ralfbrown

Oh ok. Thanks for categorizing.

I was thinking a bit how this could work from a code logic perspective:

IMPORT PHOTO:

// check if file is somewhere in a subfolder of the library.db location

def find_file_in_libraryfolder(library_path, photo_file_name): 
  for root, dirs, files in os.walk(library_path): 
    if file_name in files: 
      return os.path.relpath(os.path.join(root, photo_file_name), library_path) 
  return None

result = find_file_in_folder(folder_path, photo_file_name) 
  if result: 
    //LIBRARYLOATION is written as a variable not absolute path into the database to keep it relative
    add_photo_to_library($LIBRARYLOCATION/result/photo_file_name)  
  else: 
    DO THE NORMAL DARKTABLE IMPORT WITH THE EXISTING CODE

OPEN PHOTO IN DARKTABLE

//construct the absolute path of a photo when opening a file within the library.db folderstructure
def resolve_photo_file_path(library_path_variable, file_name):
    # Get the actual path from the environment variable
    base_path = os.getenv(library_path_variable)

    # Traverse the base path to find the file
    for root, dirs, files in os.walk(base_path):
        if file_name in files:
            absolute_path = os.path.join(root, file_name)
            return os.path.abspath(absolute_path)
    return None

resolved_path = resolve__photo_file_path($DARKTABLE_LIBRARY_PATH, file_name)

if photo_path contains $LIBRARYLOCATION
  photolocation = resolved_path($LIBRARYLOCATION, file_name)
else:
    DO THE NORMAL DARKTABLE PHOTO OPENING WITH THE EXISTING CODE

I hope this makes sense.

titan3025 avatar Dec 16 '24 08:12 titan3025

This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

github-actions[bot] avatar Feb 16 '25 00:02 github-actions[bot]

Yes personally I am after the same feature IDK if the implementation proposed is the right one but we definitely need something like that. how are we supposed to backup our work without that. Nobody fears a disk fail there ?

Having the option to put the db in the root folder would be a great start for non power users.

I don't know how the library db is handled in code but if it is wrapped at all (I hope so ..) we only need to intervene in that wrapper.

wrapper.openDB <= allow a personalized path wrapper.getPath <= allow a personalized path prefix then wrap that in a GUI

Rational-pi avatar Sep 28 '25 14:09 Rational-pi

how are we supposed to backup our work without that

The xmp files with your images are a backup that the database can be reconstructed from.

I don't know how the library db is handled in code

There's actually 2 database, library and data.

When darktable started the decision was made to go with one set of databases. 16 years of code has been built on top of that decision, so any changes would be a MAJOR undertaking.

darktable does give you a way to do it with the --configdir --datadir --cachedir flags so you could start darktable with those arguments pointing to wherever you want to store it. You could even wrap it in a script and store the various "library" locations so that you specify the library and the script starts darktable with the correct argment

wpferguson avatar Sep 28 '25 18:09 wpferguson

darktable does give you a way to do it with the --configdir --datadir --cachedir flags

Nice to know. Thx

The xmp files with your images are a backup that the database can be reconstructed from.

If that were totally true that would be perfect, but if I understand right, grouping does not live in XMPs.
I just moved my root folder and had to patch library.db manually to avoid the pain of manually editing each folder in DT

Rational-pi avatar Sep 28 '25 19:09 Rational-pi

but if I understand right, grouping does not live in XMPs

There's a fix for that, but it's still in testing

wpferguson avatar Sep 28 '25 20:09 wpferguson

This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

github-actions[bot] avatar Nov 29 '25 00:11 github-actions[bot]