IMatch failed so miserably on a simple task ...

[real_skydiver]

Today I decided to change my folder-structure slightly. My (now) 'old' schema was like '//SERVER-NAME/photo/Photos/2000.02' - where the last folder name obviously is build out of year and month. Now I have changed that to '//SERVER-NAME/photo/Photos/Photos/2000/02'  . This seamed much more convenient, since the number of photos grew over the years to somewhere in the neighbourhood of 150k.
Now, I though that would be such a easy task in IMatch to move the location of my pictures - but I was wrong. Big time.

First I changed my folder structure on my NAS accordingly. That only took a few minutes, I Moved all folders from on year in that corresponding 'year'-folder and renamed them with 'BulkRenamer' so that they got rid of the year in their name.
The I went to IMatch and started with the top one folder, right click "Move ...". The dialog was simple to satisfy, just put a slash where there was a dot. And sure enough, the dialogs OK-button confirmed by getting active, it was able to locate the pictures in the new folder. Clicked OK and ... found a '02'-folder under '//SERVER-NAME/photo' in the IMatch folder tree - but there isn't a '02' folder under '//SERVER-NAME/photo' on my NAS. I restarted IMatch - no success. The I clicked (totally frustrated) on 'Refresh drive ...' - which I shouldn't. It started to scan the folder on the NAS, I interrupted it and - what a surprise, a '2000' folder showed up underneath '//SERVER-NAME/photo/Photos/Photos'. Now I dragged the '02' folder from above into the '2000' where it belongs. IMatch started to move thousands of files from  '//SERVER-NAME/photo/Photos/Photos/2000/02' to '//SERVER-NAME/photo/Photos/Photos/2000/02' - so from and to the exact same location. I though this is ridicules but if that helps to reorganize my photos - it's ok with me. But it didn't. It left the old folder '02' - now empty - underneath '//SERVER-NAME/photo' and the '02' folder under '//SERVER-NAME/photo/Photos/Photos/2000' never showed up. So it's basically gone. No worries, I have half a dozens backups - and the folder '//SERVER-NAME/photo/Photos/Photos/2000/02' is actually still on my NAS.

My next idea was, ok, what the heck - lets build a new database (even if this runs for days). The only thing I need are my categories. The plan was - if the export format is somewhat like txt or xml to write a little program to tweak the structure in that file so that it matches my new file structure. But here comes the next big disappointment. Whatever category (single one, portions of my tree) I dragged on the export area, it only wrote a (basically) empty xml (with a bit of header and stuff like this). I repeated those steps several times, which on one occasion even crashed IMatch ...

Honestly, in only a few hours I totally lost faith in this software.

Funny though, a few moth ago I asked why IMatch wouldn't be available with a 'real' Database in the back (I'm pretty sure that even MySQL could handle at least the amount of records the current file based DB can hold). Now, if it had such a DB in the back my change would been only one line of SQL .... jmtc

[Mario]

I'm not quite sure that I can follow your post.
Did you read the "File Management" help topic in IMatch?

Which kind of problem did you encounter?
Did you keep the IMatch log file so we get more detailed information about the error you encountered?

Many IMatch users, including myself, manage their image collection on NAS boxes.


The database technology used by IMatch is also used by companies like Google, Apple, Microsoft, Adobe and Boing. It's a real database system, just embedded and without the need to run and maintain separate database server.

[hro]

Not quite sure what you are trying to achieve and what problems you exactly encountered.

If you  wanted to restructure your folders I would have done this first and then simply do a relocate in IMatch. I do this all the time and never encountered a problem.  If you also wanted to rename your files I would have done this next in Imatch, after your folders were relocated.  I also do this all the time with my files on a NAS.  Never had a problem with this.

The help system explains this in very detail,  just need to read it.

NB, SQLite is a very robust and fast database management system used for embedding it in applications. Many reputable vendors are using it,  including Adobe who are using it in Lightroom   

[sinus]

Hm.
I move, copy, rename files and folders quite a lot.

I had never problems. I do all inside IMatch. Works always really great.

Did you read the importants help-file-information for that, what you want to do?

You have problems, where  a lot of other users seems to have no problems.
Or you want to do something, what I do not understand.

[Mario]

NAS systems are usually Linux systems. To make the Linux file system on the NAS accessible for Windows, NAS systems simulate a Windows file system using a software called SAMBA.

When you access the file system on a NAS from Windows, the commands sent by Windows to the NAS are intercepted by SAMBA, transformed into Linux file system commands, carried out and the result is again transformed into the protocol Windows expects.

Usually this just works and there is no difference between accessing a remote Windows PC or server and a NAS box in Windows Explorer or IMatch. It's usually slower, but that's the major difference.

But in the past there occasionally have been problems with old or buggy Samba implementations, NAS boxes who caused problems when under stress (e.g. restructuring large file systems) etc. All this problems happen outside of IMatch, but IMatch may be the application where the problems show up.

IMatch does not move or copy files directly. Instead it uses the same functions as Windows Explorer (Windows shell functions). This ensures optimal compatibility with all the different file system incarnations Windows uses, support for the recycle bin, the standard copy/move progress feedback user interface for the user etc.

If there are problems, the Windows functions report these back to IMatch. IMatch logs the error messages into the log file and informs the user.

[Mario]

NB, SQLite is a very robust and fast database management system used for embedding it in applications. Many reputable vendors are using it,  including Adobe who are using it in Lightroom   

Google uses SQLite as the database system for Android and in Chrome everywhere.
Firefox uses it as its database engine.
Apple uses it as the database for iOS.
Adobe uses it e.g., in Lr.
Microsoft uses it for Cortana and Skype.
Airbus uses it in their plane software.
...

Since IMatch switched to SQLite back in 2008 it always proved to be a good choice.
There are IMatch users out there who manage asset databases with more than 1 million assets!

And with IMatch Anywhere IMatch becomes a real client-server system. IMatch WebServices run on the server and do all the work. Only the data needed by the client (web site or app) is transferred over the network. Best of both worlds, really.

[real_skydiver]

Sorry, that my text became a bit long. Basically what I did was to use the "Relocate Folder" function AFTER I changed my folder structure on my NAS. And that was the point, when the trouble started. The folder tree afterwards showed a really strange structure (certainly not matching the folder structure on my NAS). The 'month'-folders where shown one hierarchy-step above the 'year'-folder, where the should have shown up beneath (or rather 'in') the 'years'-folder. And it did this with every folder I tried ....

[Mario]

When you use the Relocate command to, e.g., relocate the folder

c:\images

to

\\NAS\share\images

IMatch performs some checks to ensure that the images folder and sub-folders exist on the relocation target. Then it replaces all references of "c:\images" with "\\NAS\share\images" in the database.
Or  "c:\images\year\2015\june" with "\\NAS\share\images\year\2015\june".  This process does not change the folder structure maintained in the database or anything. It's basically a text replace,

Note: Did you press <F5> once after relocating to refresh the folder tree? Sometimes if the relocation takes a long time or the target device is slow to respond, the tree may not update due to timing constraints. Pressing <F5> to refresh it or closing and re-opening the database does the trick.

I suggest you relocate one folder after the other to ensure that IMatch understands exactly what you want to do.

Note 2: After relocating the folders have been relocated, IMatch treats then in the standard way. It listens to file system notifications sent by Windows about changes done to these folders. It also compares the timestamp recorded for the folder in the database with the timestamp returned by Windows (Samba / Linux in your case). If they differ, IMatch assumes that the folder has been changed and starts to rescan it to find new and updated files. And sub-folders.

[real_skydiver]

My change was even simpler then the one that you used in your example ... or maybe to complex after all ...

I changed from

\\NAS\share\images\2001.02

to

\\NAS\share\images\2001\02

Is this possible at all?

[Mario]

You relocated the folder 2001.02 to a deeper level, producing new folders along the way:  2001\02.

Ah, now things become more clear. This may be indeed troublesome.

You are basically trying to do 3 things with one relocate:

1. Relocate the folder 2001.02 to 2001\02.
2. Change the folder structure to have one more level.
3. Add the previously non-existing folder 2001 to your database.
4. Make 02 a sub-folder of the previously non existing (and thus not indexed folder) 2001.

I'm not sure how IMatch should handle such cases in a Relocate.

I would suggest you instead to the following:

Create the folder 2001 first in IMatch.
Move 2001.02 into this folder.
Rename 2001.02 to 02.