Category & album / File system mirror

[CopperAngel]

(I've already seen the posts asking for username-based directory systems ... this isn't one of them)

I have a suggestion with regard too the directory structure scheme that is being used for storing pictures in Coppermine. Obviously currently the /userpics directory is the heart of the album system (for uploads). This is pretty nice when you are trying to keep track of who uploads what. However, since the database can keep track of this information, I think that perhaps a different system of organization could be used.

It would be great if Coppermine could modify file and directory structures to mirror the category and album structure as seen by the user.

For example, if I had a category of Celebrities with albums of Jolene Blalock and Denise Richards and Jeri Ryan, it would be nice of the directory structure was

/
/Celebrities/
/Celebrities/Jolene Blalock
/Celebrities/Denise Richards
/Celebrities/Jeri Ryan

and if I accidently uploaded a picture into Jeri Ryan that was of Denise Richards, then moved it (via Coppermine) to the correct forum, Coppermine would then move all corresponding files to the Denise Richards directory.

Why would you want to do this? Well in my case I would like for my picture organization  to exist outside the context of coppermine as well as within. With Coppermine managing the directory structure, I could easily pull all the pictures off my server and burn them onto a CD with the same organization scheme kept in tack.


I understand that I can upload existing directory structures into Coppermine and then batch add, but somtimes have huge collections of unsorted pictures. Batch uploads could even be improved this way: when I go through, I could pick all of the pictures out of an unsorted directory, add them to the Denise Richards album and they would be moved out of the unsorted directory.

[Joachim Müller]

good point, but this is a matter of performance and reliability/stability: what happens if you modify the code and the user tries to move 100 pics in one go from one album to the other? It's no problem for the db engine to cope, but to actually do the file movement, the webserver's resources would be used a lot more, resulting in a possible time-out; with part of the pics, a part not moved: an unstable condition.
You (as gallery admin) should always use ftp-upload and batch-add (you do so, as you say), but it's much easier to sort the pics in advance on the client before uploading - there are loads of free apps that do that for you in real-time.

In other words: on the first look, this sounds like an interessting point; on second thought it doesn't seem a good idea to me.
There are a lot of postings lately of users who suggest changes in the file management structure, and they all may have a point (as you have a point as well), but basically that's what having a databased gallery is good for: the database keeps track of the pics - you (the human) don't have to.

GauGau

[CopperAngel]

The performance issue is (partially) a moot point.

Admittedly, I don't know that much about the way Linux handles files, but at least on a windows box, even moving a few thousand files would take  one or two seconds IF the files were on the same partition ... no moving hundreds of megs of data, just a few thousand Kbs of data as the File Allocation Table (or corresponding structure) is modified. That's the way linux does it to, isn't it?

The performance impact of moving thousands of files is almost negligible. The only sticking point would be making sure that when files are being moved that they are on the same partition. This might be an issue with symlinks (in linux) or junctions (in windows) ... but still, I think that some consideration still deserves to be given with regard to the directory structure.

[Joachim Müller]

There'll be thoughts on the file structure when it comes to planning cpg2; every aspect will have to be taken into account - I guess your approach is not bad, we (the dev team) will discuss it then.

GauGau

[CopperAngel]

thanks.  

[CopperAngel]

For those who might be interested, I have created a script that will perform the directory changes as described in this script.

http://forum.coppermine-gallery.net/index.php?topic=4345

BEWARE, it's an first-draft script, so it's not perfect. Don't use it if you can't back up your board.

[The_Nighler]

good point, but this is a matter of performance and reliability/stability: what happens if you modify the code and the user tries to move 100 pics in one go from one album to the other? It's no problem for the db engine to cope, but to actually do the file movement, the webserver's resources would be used a lot more, resulting in a possible time-out; with part of the pics, a part not moved: an unstable condition.
You (as gallery admin) should always use ftp-upload and batch-add (you do so, as you say), but it's much easier to sort the pics in advance on the client before uploading - there are loads of free apps that do that for you in real-time.GauGau

Here's the solution! Instead of using name, simply take nummers! Don't understand?

Well:

Let's take this:

/
/Celebrities/
/Celebrities/Jolene Blalock
/Celebrities/Denise Richards
/Celebrities/Jeri Ryan

And make this to (bear in mind, that in admin cp, and on the index, there still are the full names, means name is copled to number):
/
/1/
/1/11
/1/12
/1/13

Or something like that, it doesn't matter.

Now, if I change

/
/Celebrities/
/Celebrities/Jolene Blalock
/Celebrities/Denise Richards
/Celebrities/Jeri Ryan

into this:

/
/damnit/
/comics/spawn
/movies/texas
/pirates/captncook

the number still are:

/
/1/
/1/11
/1/12
/1/13

I think this is the perfect solution.

Now, if you want to move these pictures from:

/
/damnit/ (1)
/comics/spawn (1/11)
/movies/texas (1/12)
/pirates/captncook (1/13)

to

/Celebrities/ (2)
/Celebrities/Jolene Blalock (2/21)
/Celebrities/Denise Richards (2/22)
/Celebrities/Jeri Ryan (2/23)

you can to this from picture to picture, or by a batch, or something like that.

It think this problem is solvable.

Hope I gave you a hint.