#1 2007-01-11 07:38:25

MeSat
New member
Registered: 2007-01-11
Posts: 2

Image issue when moving database.

Hello,

First, thanks for a great product.  It saved me writing a DB for our movie/video game collections.  I have already recommended this to program to a couple of friends.

Now the issue.

My wife spent a few days entering our various items into two databases.  Using the search feature to get the images.  She did this on the laptop but we wanted to move the files to the server.  Great, but no images.  Found the preferences and changed them to point to the image directory after moving it from ~/{user}/... to the common database directory.

The *.gcs file shows the correct data for the directory but the images are lost as the preference changed the path but didn't save the file name under <boxpic></boxpic> (Video Games) or <image></image> (DVDs).

A simple solution would be to have the image referenced by two tags.  <image_path></image_path> and <image_name></image_name>.

Also if the default selection was to use the title instead of just a number, I wouldn't have to research each DVD again to get the images.

version
gcstar-1.0.0-1.fc7

Fedora Core 4

I see this as a bigger problem if you try to restore the data after a system crash on a new drive or on a new install where paths can be different.  With the paths separate from the file name, the path can be easily changed.

Using my present installation, I have ~/{user}/data/Database/gcstar/images/ so the image tags would be

<image>/home/{user}/data/Database/gcstar/images/{some_movie}.jpg</image>

If I decide to move the images to /home/{user}/data/Database/gcstar/DVD/images and then change the preference, the image tag is changed to

<image>/home/{user}/data/Database/gcstar/DVD/images</image>

and the reference to {some_movie}.jpg is lost.  As the default uses a gcstar prefix, this makes matters really bad for editing the XML file to correct this.  I am hoping to edit the original file reflect the move.

With my suggestion,

<image>/home/{user}/data/Database/gcstar/images/{some_movie}.jpg</image>

becomes

<image_path>/home/{user}/data/Database/gcstar/images/</image_path>
<image_name>{some_movie}.jpg</image_name>

Now the path can be changed at will and still reference the image in the directory.

Until this is fixed, users will just have to be careful.

Offline

 

#2 2007-01-11 10:58:19

Tian
Administrator
From: France
Registered: 2006-12-08
Posts: 1647
Website

Re: Image issue when moving database.

Hello,

First, if you still have to move a collection from a machine to another one, you may use .tar.gz export/import as explained here:

http://www.gcstar.org/questions#save

It will ease this process.

Concerning the problem of the stored path in collections, there is a task that could fix that:

https://gna.org/task/?4282

Actually it will be done by storing the picture path in the collection itself as you suggested. But this will be done only once for a collection, not for each item (I must admit I don't see what could be the benefits for this method). It will also be possible to use a tag in the path to specify the path is relative to the directory where the collection is stored. So it will be easier to move a collection.

Do you think this would fix your issues?

For the names of pictures, I will change the default option so it will use item name instead of a generated file name.

Thank you for your report.

Offline

 

#3 2007-01-12 05:43:47

MeSat
New member
Registered: 2007-01-11
Posts: 2

Re: Image issue when moving database.

Tian wrote:

Hello,

First, if you still have to move a collection from a machine to another one, you may use .tar.gz export/import as explained here:

http://www.gcstar.org/questions#save

It will ease this process.

I will have to test this to see if it works as expected.  I do see this as still being a problem though if you want to share the database.  In my case this is what happened.  My wife created the database and we were moving it to the server where we could both access it.  If our paths are set wrong, the database is now toast.  The default setting is as stated, in a subdirectory of the {user}.

Tian wrote:

Concerning the problem of the stored path in collections, there is a task that could fix that:

https://gna.org/task/?4282

Actually it will be done by storing the picture path in the collection itself as you suggested. But this will be done only once for a collection, not for each item (I must admit I don't see what could be the benefits for this method). It will also be possible to use a tag in the path to specify the path is relative to the directory where the collection is stored. So it will be easier to move a collection.

Do you think this would fix your issues?

For the names of pictures, I will change the default option so it will use item name instead of a generated file name.

Thank you for your report.

That is it in a basic form.  Now some reasons as to why I think it is important to make the change.

Under  Preferences > Paths, I can set this up.  The checkbox for Use relative paths for images provides this feature and I feel should be the default setting.  But the problem I ran into is changing the Images directory after the database is setup loses the data in the <image></image> tags.

I did a simple test and I just got a surprise as my understanding is different than what the program does.

For me, the relative path should be based on the data file, and just the datafile directory and shouldn't have anything to do with the {user} directory.  This will only cause no end of headaches if the database is shared as in my case. 

Now for the example.

I set up a test database with three items.  The first two items were entered with a image path /home/family/data/Database/test/ and saved the *.gcs file in /home/family/data/Database/test/.  The actual tag ended up being <image>../../../../mesat/../family/data/Database/test/Animal_House_0.jpg</image>

I then changed the path to just image but left the relative path checked.  Now the new entry was actually created in my home directory, not the database directory where I expected.   <image>../../../../mesat/images/Alien_0.jpg</image> which left the images unaccessible to someone else that wanted to access the database.

My understanding of relative paths would have had the image tag show <image>./home/family/data/Database/test/Animal_House_0.jpg</image> in the first example and <image>./images/Alien_0.jpg</image> in the second example. 

Now this shows a problem that I didn't see at first.  The relative path references the {user} that entered the data.  On a shared network, this users home directory may not always be there.  An example that I look at is where I work, my home directory is mounted via NFS so it only is on the network when I am logged in under /home/{user}.  On my desktop the actual home directory is /export/home/{user}.  Of course, down the road, this could change if the IT people decide to change it.  At home I am going to be using NFS shares for the various computers so all the data is stored on the central file server.

All the database work I have ever done has had a relative path based on the the database directory.  It would always be based on something like ./data/, ./scripts/ and ./forms/.  This allows the OS to copy or move the database with ease.  I can then use normal backup tools to store the data and reconstruct it.  In my above test, I could login as a different user or even move the file to a memory stick and work from it on any machine that I want to.  I don't have to worry about paths.

You may have had a reason to store the files the way you did but I see if from an administration point of view if the machine needs to be rebuilt or changed.

Two changes that would help by default and without looking at the source code would be to turn relative paths on and turn on the Prefix to use for pictures: Title or name of the associated item.

I did download the source to take a look.  I will have to shake out some of the rust and cobwebs in my brain to see if it makes any sense to me.

I hope this helps to clear things up a bit.

Offline

 



Should you have a problem using GCstar, you can open a bug report or request some support on GCstar forums.