Dear Jean and all,
eventually we took a look on the old GN instance, we discovered a data dir outside the GN,
that's why when I made the backup on the old instance in the new server I didn't found
any data related to the metadata (just to be clear: no files there were in the Private directory in
the exported metadata - I mean the file .zip (mef)).
The we migrated the data dir in the new instance of GN (in the new server) and everything went well,
in particular we put the data dir in the default data dir in: WEB-INF/data/data/metadata_data
and it worked fine!
I think everything is now ok, I can say that we made a complete migration from an old version (2.8.x),
to a new 2.10.3 in a new server for all the metadata (581) maintaining the also the correct categories.
Thanks to all
Eugenio
Date: Mon, 17 Nov 2014 12:45:38 +0100
From: jean.pommier@anonymised.com
To: frippe12573@anonymised.com; geonetwork-users@lists.sourceforge.net
Subject: Re: metadata uploaded file on GN migration was: batch import
Wow, it looks weird. On your old instance, was it still possible to
download the data ? Or see the thumbnail ? Are you sure you didn't
externalize the geonetwork datadir ? Can you still run the old
instance ? First think to check would be that the old instance works
properly...
I'm not even sure Geonetwork would start without having a
metadata_data folder
If not, it looks like something bad happened.
Le 17/11/2014 12:16, Eugenio Trumpy a
écrit :
Dear Jean,
starting from the fact tha GN store the uploaded file in
WEB-INF/data/data/metadata_data,
I see that in my GN backup (I mean the old GN dir deployed in
app server) there is no that directory
but I have only WEB-INF/data/data/removed where there are other
subdir containing *.mef file.
On the other hand the backup of the metadata (I made it from the
running old GN using 'export' command),
doesn 't contain any file in the 'private' directory.
I guess that's why on restoring the backup on the new GN I have
no the resources needed for download.
Could be possible? How could solve this issue?
Regard
Eugenio
Date: Mon, 17 Nov 2014 10:46:43 +0100
From: jean.pommier@anonymised.com
To: frippe12573@anonymised.com;
geonetwork-users@lists.sourceforge.net
Subject: Re: metadata uploaded file on GN migration was: batch
import
Hi Eugenio,
Yes, GN stores the files in WEB-INF/data/data/metadata_data
unless you tell it to place the metadata_data folder somewhere
else.
When you export some MEF files, the associated files should be
exported with them. If you unzip the MEF archive, you'd find a
'public' folder, that will contain the thumbnail and picture,
and a 'private' folder containing you associated files.
Please check that you have the files in this private folder
(for metadata that do have associated file, of course)
Is your new instance accessible on internet ? I'd like to
check something. As I told you, I would say that the issue is
a change in the URL to access the catalog (and thus, to access
the files) between your old instance and the new one.
Jean
Le 17/11/2014 10:30, Eugenio
Trumpy a écrit :
Dear all,
just to be clear I changed the object of the topic since
the main issues on batch import are now solved.
However, as I reported in the last email here below, I
have some problems on the files uploaded for each
metadata.
The previous situation was: in my old GN I had about 580
metadata and some of them had the related uploaded
zip file. I think GN stores the uploaded file in
WEB-INF/data/data/metadata_data but I don't know what
happens in the export procedure.
Or does GN store the uploaded file in its mckoi db?
Anyway I exported all the metadata from the old GN and I
restored the backup on the new GN.
Of course I changed the URL in the OnLineResources tag of
the backuped metadata according to the new name server.
I suspect that the backup of the old GN was not complete,
it missed the dir metadata_data where the uploaded zip
should be.
What about?
Regards
Eugenio
--
Jean Pommier -- pi-Geosolutions
Ingénieur, consultant indépendant
Tél. : (+33) 6 09 23 21 36
E-mail : jp@anonymised.com
Web : www.pi-geosolutions.fr
(attachments)
