Relocate NOT both 146, 148 but different on 148

[reader]

Setup:
  Im5 [...] 148 on win7 64 bit

Before going the official bug route I'd like to have a few experienced hands take a look at what I'm seeing.

The problem seems to be that IM5 is not able to relocate in the circumstance I have in this environment.

Reason to relocate:  I had a serious crash of the OS not related to IM.  I decided then to re-install complete from ground up.
So, the OS is still rather new but up to speed by way of updates and installed software.

During the rebuild I inadvertently named 2 smb shares differently than before the crash.

So, what it comes down to is relocating from the old share name to the new.

..Old share name: \\m2\sg-ext-2t\
New share name:   \\m2\sg-ext2t\

On version 146, when I right clicked and selected 'relocate' the dialog would not come up at all.

Today, after installing 148... on restart; attempting to 'relocate' with right click, select 'relocate'
I get the dialog but my efforts within that dialog end in a sort of exasperating way.

Perhaps it is some kind of 'Pilate error' (somewhat likelier ) or perhaps it is an actual problem with the code.

The image attached shows me having typed in the right address; the old location is also selected as the top level to relocate.

But when I press ok, I get the dialog in center saying (paraphrased) None of the stuff at the old address is found at the new.
Im5.148_relocate_AddrInsertedManly.jpg

If I navigate to the desired address thru the dialog; you can see the address Im generates
does not include the full address and has the slashes unix style.  (//), Perhaps Im recognizes both but the full path
I navigated to is not present.

Pressing OK results in the above referenced dialog.  Manually adding the rest of the address by hand, continuing the unix style slashes
also ends in the above referenced dialog.
Im.148_relocate_Navigated.jpg

In the first image; you can see the old address Im has:\\M2\sg-ext-2t
. . . . . .  . . . . . . .. .. .. .. .and the correct new address:\\m2\sg-ext2tb

The final image is a shot of the new address as found in windows File browser: Im5.148_relocate_ActualAddress.jpg

For the record: You might think I could simply change the name to the new address.  But, I am unable to do so.  No
'rename' is present on the context menu and trying with F2 does not allow my editing.

A final point:  Perhaps I could just name the shares back to the old names.  Well, yes I could but there would be a
certain amount of other thing to change on other machines etc.  And the relocate process should do the job.

[attachment deleted by admin]

[Mario]

Tried that here and it works.

I relocated a share from "\\machine\abc"  "machine\xyz" after renaming an existing share.
I used the same steps as you did. The forward slashes are no problem. IMatch internally uses operating-system independent URIs with / instead of the Windows \ but that's all handled.

I could successfully relocate an entire folder hierarchy from one share to another.

IMatch expects that the folder hierarchy you relocate exists identically on the new share, all folders and files. If it cannot find folders or files, you get the error message you have mentioned. The same happens if IMatch is unable to access the folders on files on the new location. Did you check that the file system privileges are set properly? Any errors or warnings in the log file?

[reader]

Tried that here and it works.

I relocated a share from "\\machine\abc"  "machine\xyz" after renaming an existing share.
I used the same steps as you did. The forward slashes are no problem. IMatch internally uses operating-system independent URIs with / instead of the Windows \ but that's all handled.

I could successfully relocate an entire folder hierarchy from one share to another.
IMatch expects that the folder hierarchy you relocate exists identically on the new share, all folders and files. If it cannot find folders

When you say "identically"... do you mean that if one file is missing the whole thing will fail?  I hope not. Or do you mean in terms of position on the share.   If the latter, then that is true here.

or files, you get the error message you have mentioned. The same happens if IMatch is unable to access the folders on files on the new location. Did you check that the file system privileges are set properly? Any errors or warnings in the log file?

Thanks for the reply. 
Since you've experimented successfully with the same issue... I'm at a loss to explain the problem I have... but it apparently is a 'LOCAL' (read 'pilot') caused problem.

I have attached 4 images and the debug Log file, to try to further clarify... and possibly you will see my error or other environmental factor causing my problem.

First, concerning permissions; The share is on a usb3 attached external drive.

The attached image titled 'IM_permissions.jpg' shows that "Everyone" has "Full" control.
Further, thru a file browser, I've opened and edited a perl script on that share.  Not sure if that shows much about permisisons for IM but at least my user has reader/write permissions.

In my case (as opposed to the one you describe) the files are a little bit deeper into the share.  The actual share changed from:

//m2/sg-ext-2t
to
//m2/sg-ext2tb

However, in both cases the top level of Im Hierarchy starts at:
//m2/sg-ext-2t/ImagesMusic/ImageDB (old)
to
//m2/sg-ext2tb/ImagesMusic/ImagesDB (new)

Attached image ( titled IM_OldHierNewHier.jpg) Shows what IM5 shows as the missing Hierarchy and what a file browser shows of the correct hierarchy.

There may be some small changes in the files there...in the way of added file or the like, but not inthe way of what level the DB begins on.  As you see, both show the top level as ImageDB.
And the absolute vast bulk of the data is identical.  I assumed one could rescan to pick up possible added/removed files.

All I did to throw location off is give the share a new name (Exactly what you've done..).When I attempt to relocate.  In the first dialog, I use the '[...]' button to traipse more deeply into the share to attain the above address.
However when I click ok at the correct address (//m2/sg-ex2tb/ImagesMusic/ImageDB) all that remains in the dialog is:
//m2/sg-ext2tb  <== No path beyond is shown.

Two images attached... showing having traipsed to the correct address (IM_TraipseToAddr.jpg) and what happens on [OK] (IM_PostTraipse.jpg)

And when I press ok again.... it ends in the error message I posted.

[UPDATE: NOT SURE WHY ALL THE STRIKE THRU happened... must be some miss use I've done with '[]'

========================================================================

I've now conducted a new experiment and changed the share name back to the original... Im5 finds it just like before... I've ran a rescan... IM5 seems
to have found around 215 new files... processed them... and away we go...

Now to change the name once more, now that we know the trees will be identical, and see what happens ....  Whoops.... I take back some of above
IM appears to be reprocessing the whole bunch.   First it listed 215 of some much bigger number to be processed... I thought that meant that was all the changed files it had found.
but now I see it background processing 6,876.   What does the first reading of 215 mean then?  Will attache that debug log in a new message since I'm already
at the limit.

I've got 1.3 hr wait so I'll post without continuing this experiment yet.

[attachment deleted by admin]

[Richard]

NOT SURE WHY ALL THE STRIKE THRU happened...

Since you didn't seem to want the strick thru I edited out ALL of them.

[Mario]

IMatch expects the target for the relocate to by a 1:1 copy of the original structure. Relocate is designed to allow you to correct problems caused by renaming files and folders in other applications, or things like a replaced hard disk or renamed share. In all cases, IMatch maps the internal structure of the database from the old location to the new one. No files or folders can be added or removed during this process, which is why IMatch runs checks to ensure that the layout of the relocation target matches the source 1:1.

If IMatch finds files to rescan/add, the file and folder structure of the target is definitely different and relocate was right to refuse it.
Since you have no renamed the share, do a full rescan. If IMatch has completed that, you can rename it back and the relocate should report no problem.

[joel23]

In all screenshots IMatch shows a missing folder named "imatch" beneath "ImageDB" whereas in the explorer it is to see at the same level (outside "ImageDB).

Anyway, you are trying to relocate the share \\M2\sg-ext-2t\ itself. Relocate "ImageDB" instead - means right click this folder in IMatch, choose relocate and point it to the right folder in the new share.  The share (name) will appear automagically in IMatch after that.
The missing path elements after navigating and selecting the folder within the share, is a result of what you are trying to do: IMatch jumps to the root of the volume or share.





[attachment deleted by admin]