Bug: managed repo broken by omero.data.dir move

[jamoore]

Seb recently migrated the gretzky server to the new octopus server. The change in the name/location of the ManagedRepository? led to all the data going missing since a new mrepo was created:

[jamoore@ome-c6100-1 ~]$ ~hudson/OMERO-CURRENT/bin/omero fs repos
# | Id    | UUID                                 | Type    | Path                                                                                       
---+-------+--------------------------------------+---------+--------------------------------------------------------------------------------------------
0 | 17    | ce1e2766-089f-4555-a52a-f75746fd44da | Public  | /OMERO                                                                                     
1 | 18    | ScriptRepo                           | Script  | /home/hudson/hudson/workspace/OMERO-merge-stable/src/dist/lib/scripts                      
2 | 10901 | 28360f82-977c-4764-b52c-f31d677ebbaa | Managed | /nightshade/OMERO/omero-c6100-dec-5-2013-valuable/OMERO-merge-develop-FS/ManagedRepository 
3 | 88301 | 7ef9e3dc-20e3-43a2-85f8-223431e40058 | Public  | /repositories/OMERO-5.0-merge-deploy                        

and

OMERO-5.0-merge-deploy=# select repo, count(*) from originalfile group by repo;;
                 repo                 | count 
--------------------------------------+-------
                                      | 14187
 28360f82-977c-4764-b52c-f31d677ebbaa | 57564
 ScriptRepo                           |    23
(3 rows)

Note: symlinks are also broken more thoroughly since the files are not located on the new server but this is an unrelated issue.

[jamoore]

In addition, the bfmemo files are holding onto filenames:

Caused by: java.io.FileNotFoundException: /nightshade/OMERO/omero-c6100-dec-5-2013-valuable/OMERO-merge-develop-FS/
ManagedRepository/user-1_8/2014-05/27/09-26-52.983/Experiment-519.czi (No such file or directory)
        at java.io.RandomAccessFile.open(Native Method) ~[na:1.7.0_55]
        at java.io.RandomAccessFile.<init>(RandomAccessFile.java:241) ~[na:1.7.0_55]
        at loci.common.NIOFileHandle.<init>(NIOFileHandle.java:124) ~[formats-common.jar:na]
        at loci.common.NIOFileHandle.<init>(NIOFileHandle.java:135) ~[formats-common.jar:na]
        at loci.common.NIOFileHandle.<init>(NIOFileHandle.java:144) ~[formats-common.jar:na]
        at loci.common.Location.getHandle(Location.java:323) ~[formats-common.jar:na]
        at loci.common.Location.getHandle(Location.java:293) ~[formats-common.jar:na]
        at loci.common.Location.getHandle(Location.java:283) ~[formats-common.jar:na]
        at loci.common.Location.getHandle(Location.java:273) ~[formats-common.jar:na]
        at loci.common.Location.checkValidId(Location.java:348) ~[formats-common.jar:na]
        at loci.formats.ImageReader.getReader(ImageReader.java:177) ~[formats-api.jar:na]
        at loci.formats.ImageReader.setId(ImageReader.java:750) ~[formats-api.jar:na]
        at loci.formats.ReaderWrapper.setId(ReaderWrapper.java:569) ~[formats-api.jar:na]
        at loci.formats.ChannelFiller.setId(ChannelFiller.java:259) ~[formats-bsd.jar:na]
        at loci.formats.ReaderWrapper.setId(ReaderWrapper.java:569) ~[formats-api.jar:na]
        at loci.formats.ChannelSeparator.setId(ChannelSeparator.java:270) ~[formats-bsd.jar:na]
        at loci.formats.ReaderWrapper.setId(ReaderWrapper.java:569) ~[formats-api.jar:na]
        at loci.formats.Memoizer.setId(Memoizer.java:480) ~[formats-bsd.jar:na]
        at ome.io.bioformats.BfPixelsWrapper.<init>(BfPixelsWrapper.java:51) ~[romio.jar:na]
        at ome.io.bioformats.BfPixelBuffer.reader(BfPixelBuffer.java:73) ~[romio.jar:na]

[jamoore]

PR opened for repository naming: ​https://github.com/openmicroscopy/openmicroscopy/pull/2673

Haven't begun to look into the file-specific issues yet.

[jamoore]

The CZI error seen by Sebastien is almost certainly related to in-place import and so will be handled elsewhere. There *may* still be some issue with the bfmemo files, but at the moment I don't have evidence of any. Closing.

[jmoore <josh@…>]

(In [310be3f12ea722dddc69a92c0d819c40f9a57599/ome.git] on branch develop) Rename don't recreate repos on move (Fix #12355)

If a sysadmin properly moves the omero.data.dir to
new location via:

`

bin/omero config omero.data.dir NEW
mv OLD NEW

`

then there's no reason that a new repository should
be created. Instead, now a WARN log statement is
printed and the new value should be visible via
bin/omero fs repos. Imports of files from before
and after the renaming should work identically.

[Josh Moore <josh@…>]

(In [c47c48c8c106f7d7b5330eafacd9d5eacfa95cab/ome.git] on branch develop) Merge pull request #2684 from joshmoore/rebased/develop/12355-move-dir

Rename don't recreate repos on move (Fix #12355) (rebased onto develop)