maybe my posting wasn't that clear: of course you can have multiple links inside the db pointing to one file location, but consider these scenarios:- the "original" pic (which has been added to the gallery in the first place and resides within an album structure that reflects the gallery's structure) is being deleted - what will happen to the links within other albums?
- coppermine features multi-users, user upload and a permission system (many request a more sophisticated permission management, with sub-groups etc.). What happens if the "original" album's permsiion settings change?[/list:u]Although the feature you request may be helpfull for you (and of course some others), it will make administration of coppermine more complicated for newbies.
My reference to hard links was not intended as a OS-specific solution, just an observation that the problem is not new, and has been solved.
To clarify: there are two good ways to address this issue:
1. The 'cleanest', but most expensive in terms of DB lookups, is to have a new DB table that links the tuple of (filename,reference count) to a key, and everywhere that the DB currently points at a file name, have it point at an entry in this new table. When adding the files, entries are created with a reference count of 1; when creating duplicates, the reference count is incremented, and when deleting photos, the ref. count is decremented. When ref=0, delete the physical files and the entry in the table. This is precisely how hard links are managed in Unix. However, every picture access involves an extra DB lookup.
2. Less clean, but more efficient: borrow the "soft link" model (or that of the Windows 'shortcut' facility). A picture "belongs" to a single, specific album, but soft links in other albums can point to it. The drawbacks are as GauGau observed, but I don't think either represents a huge problem. In the case where the target of the soft link disappears (because it was deleted), an attempt to access the link could either result in the link being silently deleted or a "pic not found" placeholder being substituted. The permissions thing is, I think, not important in that *if* a pic was accessible at the time of the link being created, then the link creator could have simply downloaded and re-uploaded the pic.
Oh, and I suspect this facility (however implemented) would be *very* popular with many people: the ability to create entries in both "My Friends" and "My Parties" for the same pic is kinda attractive!
@malc: I agree that Lunix is the best platform for webservers, that it's most powerfull etc., but you can't deny the fact that a lot of coppermine users are running coppermine on Windows/IIS (like it or not - I disapprove of it as well!). That's why I vote against a platform-dependent solution.
My point had little to do with the virtues of the OS, and everything to do with the implementation of soft links vs hard links in Unix. Still, I believe that NTFS implements 'Junctions', which are hard-links, although there are few, if any, tools to manipulate such things, and many tools will get confused by their (legal) presence!
But, as noted above, Unix links (soft and hard) illustrate the options...