Advanced search  

News:

cpg1.5.48 Security release - upgrade mandatory!
The Coppermine development team is releasing a security update for Coppermine in order to counter a recently discovered vulnerability. It is important that all users who run version cpg1.5.46 or older update to this latest version as soon as possible.
[more]

Pages: [1]   Go Down

Author Topic: Category & album / File system mirror  (Read 4166 times)

0 Members and 1 Guest are viewing this topic.

CopperAngel

  • Coppermine newbie
  • Offline Offline
  • Posts: 8
Category & album / File system mirror
« on: March 05, 2004, 07:42:55 pm »

(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.
Logged

Joachim Müller

  • Dev Team member
  • Coppermine addict
  • ****
  • Offline Offline
  • Gender: Male
  • Posts: 47843
  • aka "GauGau"
    • gaugau.de
Category & album / File system mirror
« Reply #1 on: March 05, 2004, 08:39:10 pm »

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
Logged

CopperAngel

  • Coppermine newbie
  • Offline Offline
  • Posts: 8
Category & album / File system mirror
« Reply #2 on: March 05, 2004, 09:09:21 pm »

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.
Logged

Joachim Müller

  • Dev Team member
  • Coppermine addict
  • ****
  • Offline Offline
  • Gender: Male
  • Posts: 47843
  • aka "GauGau"
    • gaugau.de
Category & album / File system mirror
« Reply #3 on: March 05, 2004, 09:37:53 pm »

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
Logged

CopperAngel

  • Coppermine newbie
  • Offline Offline
  • Posts: 8
Category & album / File system mirror
« Reply #4 on: March 05, 2004, 09:53:33 pm »

thanks.   :D
Logged

CopperAngel

  • Coppermine newbie
  • Offline Offline
  • Posts: 8
Category & album / File system mirror
« Reply #5 on: March 06, 2004, 08:23:37 pm »

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.
Logged

The_Nighler

  • Coppermine newbie
  • Offline Offline
  • Posts: 15
Category & album / File system mirror
« Reply #6 on: April 07, 2004, 06:50:33 pm »

Quote from: "gaugau"
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.
Logged
Pages: [1]   Go Up
 

Page created in 0.027 seconds with 20 queries.