[ome-devel] Directory exists but is not registered: CheckedPath(username_id)

[Josh Moore]

>>> So this database update seems to fix the issue, unless I've missed something else.
>>> If you know of a better way of doing this, or of a fail-fast check to prevent further mishaps, that would be useful.

>> I'm not sure I follow. What update did you perform?

> Something like this:
> update originalfile set repo = '<repo_uid_from_fs>' where repo = '<out_of_sync_repo_uid>'


I see! So, this is probably what we were working towards anyway, but it certainly depends on what steps were taken. The server is supposed to detect renames and update the repository value with a WARN log statement, i.e. this shouldn't happen depending on what you upgrade to.

But somehow it *did* happen. I was expecting the SELECT to show all the files clearly being in the wrong repo, and then I would have done what you did. If things are working for you now, that would seem to have been the correct course.

Cheers,
~Josh.

On Oct 8, 2014, at 5:18 PM, S Simard wrote:

> On 08/10/2014 17:09, Josh Moore wrote:
>> On Oct 7, 2014, at 7:29 PM, S Simard wrote:
>> 
>>> Hi Josh,
>> Hi Seb,
>> 
>>> On 06/10/2014 17:00, Josh Moore wrote:
>>>> Re: http://qa.openmicroscopy.org.uk/qa/feedback/9572
>>>> 
>>>> On Oct 3, 2014, at 1:10 PM, S Simard wrote:
>>>> 
>>>>> Hello all,
>>>> Hi Seb,
>>>> 
>>>>> During the process of migrating OMERO servers (5.0.2) between machines, I think we're hitting a problem similar to the one described in [1], thus making all imports fail.
>>>>> 
>>>>> However I can't seem to find further debugging tips in that thread, so if someone could share some of them, that would be appreciated.
>>>> One other thread you might want to look at is:
>>>> 
>>>>   https://www.openmicroscopy.org/community/viewtopic.php?f=5&t=7537&p=14109&hilit=ManagedRepository#p14109
>>>> 
>>> Thanks.
>> No problem.
>> 
>>>>> I can tell that some entries have been added to the originalfile table - what approach would be recommended to deal with them?
>>>> Could you send the result of:
>>>> 
>>>>   select count(*), repo from originalfile group by repo;
>>> I guess it's not going to tell you much now, as I have performed a database update to re-sync the originalfile 'repo' column with the value from ${omero.data.dir}/Managedrepository/.omero/repository/${db_uuid}/repo_uuid (and removed the "dangling" Repository entries), but it looks like this afterwards:
>>> 
>>> count  |                 repo
>>> --------+--------------------------------------
>>>     10 |
>>>    200 | <long_repo_hash>
>>>      5 | ScriptRepo
>>> 
>>> So this database update seems to fix the issue, unless I've missed something else.
>>> If you know of a better way of doing this, or of a fail-fast check to prevent further mishaps, that would be useful.
>> I'm not sure I follow. What update did you perform?
> 
> Something like this:
> update originalfile set repo = '<repo_uid_from_fs>' where repo = '<out_of_sync_repo_uid>'
> 
>> ~Josh
>> 
>> 
>>>> and possibly Blitz logs from around the time of the migrations?
>>> Same comment as above.
>>> 
>>>> Cheers,
>>>> ~Josh.
>>> Thanks,
>>> Seb
>>> 
>>>>> select id, atime, ctime, mtime, mimetype, name, path from originalfile where mimetype = 'Repository';
>>>>> 
>>>>> 299401 | 2014-10-03 12:53:20.3   | 2014-10-03 12:53:20.3   | 2014-10-03 12:53:20.3   | Repository | repo              | /path/to/OMERO/
>>>>> 299402 | 2014-10-03 12:53:20.327 | 2014-10-03 12:53:20.327 | 2014-10-03 12:53:20.327 | Repository | ManagedRepository | /path/to/OMERO/repo/
>>>>> 299251 | 2014-09-29 20:11:10.268 | 2014-09-29 20:11:10.268 | 2014-09-29 20:11:10.268 | Repository | ManagedRepository | /path/to/OMERO/OMERO/repo/
>>>>>     17 | 2013-07-10 10:17:30.577 | 2013-07-10 10:17:30.577 | 2013-07-10 10:17:30.577 | Repository | scripts           | /path/to/OMERO.server-xxx/lib/
>>>>>     19 | 2013-07-10 10:17:30.605 | 2013-07-10 10:17:30.605 | 2013-07-10 10:17:30.605 | Repository | repo              | /path/to/OMERO/
>>>>>     18 | 2013-07-10 10:17:30.605 | 2013-07-10 10:17:30.605 | 2013-07-10 10:17:30.605 | Repository | ManagedRepository | /path/to/OMERO/repo/
>>>>> 
>>>>> 
>>>>> Thanks
>>>>> 
>>>>> Regards,
>>>>> Seb
>>>>> 
>>>>> [1] http://lists.openmicroscopy.org.uk/pipermail/ome-users/2014-May/004417.html
>