That’s basically always going to be true regardless of where you put the file. A kdenlive/MLT project file isn’t designed to have things moved around or renamed outside of the tool that wrote that file.
Kdenlive offers an ‘archive’ option (usually intended for ‘completed’ projects) that packs up all the necessary source files into an archive that can be relocated when it is unpacked again - but I’m not sure offhand how (or if) that handles files outside of the defined ‘project directory’. Other than that, an active project file is a snapshot of where the resources were found in the filesystem structure they were contained in, it doesn’t magically track them in any other way.
I’m curious how other users work
The best way to manage your personal (or workplace as the case may be) data really depends a lot on what you’re actually doing in a much more holistic sense than just kdenlive. So I can mostly only speak for myself, and there isn’t really a One True Way that we (as a project) consider The Right and Preferred Way above all others.
Most of the footage I shoot and other AV resources I have generally aren’t specific to a single kdenlive project - so it all has its own storage structure and archive metadata completely separate from anything that kdenlive does.
Which means when I create a kdenlive (or any other) project, any files I need for that project usually get symlinked from their ‘permanent’ storage location into the directory layout that I’m using for that new project, under that project’s root directory. The only actual duplication is the backups that run for both the main store and the projects.
But if I were spending more time editing “single use” resources, that were only useful in one editing project and had little or no resuse value in some other project, I might do this a bit differently and just keep those directly in the project directory. Possibly in combination with ‘library’ resources, again symlinked in from outside.
I would generally recommend avoiding having a ‘Real Project’ (one that you intend to (be able to) return to after the current editing session is closed) refer to any resources outside of its own project directory (even if only because it makes keeping track of them much harder) - but that’s fine to do for any quick transient thing that you just want to test or quickly whip up as a one-off throwaway thing.
I’d personally be pretty annoyed if kdenlive started automatically making copies of Gigabyte-scale files just for the sake of having its own copy of them to work on - but if you want the “save everything this project needs in one bit atomic bundle” option, then you probably want to look more at this:
For ‘audio sized’ files, even high precision masters have a storage requirement that you could describe as ‘negligible’ compared to what is needed for hi-res / high quality video, so copying those isn’t quite such a big deal. But the doubling in size of Reasonably Priced Storage hasn’t kept pace with the quadrupling in storage size requirements of Reasonably Priced video cameras. The shift in research focus from increasing the density of bits on spinning metal to betting the farm on solid state storage means we’re still a few years away from being back in that blissful state where ‘normal’ storage sizes are growing faster than most people’s ability to fill them.
If you’re going to be regularly shooting and editing much 4k+ video, and not discarding your raw footage after each edit, you’re going to be filling disks pretty quickly even without redundant copies.
