Are external file renames dangerous?

[lbo]

Hi,

the docs recommend to rename files only with IMatch file management.

But I found that IMatch automatically detects an externally renamed file after a short while.

Is external rename risky or okay?

Oliver

P.S.: Wouldn't try this with folders.

[jch2103]

I think the issue has to do mostly with linked files (buddy files, versions, etc.) where an external renaming likely won't keep the renamed linked files in sync. There may be other considerations as well.

[Mario]

When you rename a file externally, IMatch loses track of the file.

For example, you rename the file "c:\images\a1.jpg" to "c:\images\a2.jpg" in some application.

When IMatch is running, it will receive file system notifications from Windows, telling it that something in the folder "c:\images\" has changed.
IMatch thus rescans the folder. Result:

The "a1.jpg" file will show up in IMatch as off-line. Because it no longer exists on disk.
A new file ("a2.jpg") is found and added to the database.

Categories, Attributes and unwritten metadata etc. are still linked to the off-line "a1.jpg".
"a2.jpg" is a new file and has only the metadata IMatch has read from the file.

Now you are in a situation. The next time you manually rescan the folder "c:\images", IMatch removes the no longer existing file "a1.jpg" and all associated data.
"a2.jpg" remains in the database, but all the data associated with the original file is gone.

IMatch monitors the "file renamed" Windows file system notifications. But they are, unfortunately, unreliably and Windows can send a "folder modified" or "new file arrived" message long before it sends a sequence of messages that indicate a file rename. Usually it works, but there may be other applications interfering, virus checkers, ...
Best not to rely on it and use the powerful file system functions included in IMatch.

Solution:

Manually remove the  "a2.jpg" from the database (context menu command) and then relocate the off-line "a1.jpg" to "a2.jpg". This links the database record to the file in the file system again, without losing any data.

[lbo]

IMatch monitors the "file renamed" Windows file system notifications. But they are, unfortunately, unreliably and Windows can send a "folder modified" or "new file arrived" message long before it sends a sequence of messages that indicate a file rename. Usually it works, but there may be other applications interfering, virus checkers, ...

Thanks for the information, now I better understand what's going on.

By chance I discovered that IMatch "magically" detected renames after briefly showing the "offline" symbol. All dots, pins flags were preserved. I thought it used some kind of checksum (didn't know about rename notifications).

After reading your explanation I will avoid external renames.

Other users might also notice that IMatch detects renames and rely on it, not knowing that it is fragile. Maybe it's useful to publish your explanation on the IMatch help.

Oliver

[Mario]

I'm quite sure I have explained that in detail and placed several alert boxes and warning messages to NOT perform file-system operations outside of IMatch in many topics. Including right at the top of the main "File Management" topic. Users don't read the help anyway.

[lbo]

I'm quite sure I have explained that in detail and placed several alert boxes and warning messages to NOT perform file-system operations outside of IMatch in many topics. Including right at the top of the main "File Management" topic. Users don't read the help anyway.

Even the users reading this warning may notice that IMatch does detect renames and from then rely on it.

Therefore I suggest to add the information snippet you posted here:

"IMatch monitors Windows file system notifications, but they are unreliable."

Your decision - we don't need to discuss this further.

I did read the warning, I did notice that IMatch detects renames but I was skeptical enough to start this thread. Other users might not do so.

[thrinn]

Even the users reading this warning may notice that IMatch does detect renames and from then rely on it.

Sometimes users might think that IMatch detected an external rename even if it did not. Consider the following example:

   
• Rename a file A.jpg that is a version of some other file (A.RAW) to A1.jpg (outside of IMatch).
• IMatch might think "Oh, A.jpg was deleted. And a new file A1.jpg has appeared".
• Now, depending on your versioning settings and if a rescan was performed and some other things, this might trigger metadata propagation.
• If the version rule includes propation of dots and pins and the new file is captured by the rule, the same dots and pins as on the original file might appear on A1.jpg. So if you look at A1.jpg, it looks like you would have expected it if IMatch has detected the Rename. That is, if you only look at dots and pins. But in fact, this did not happen at all!

My conclusion: Do not rename managed files outside of IMatch!

[sinus]

My conclusion: Do not rename managed files outside of IMatch!

Absolutely correct.
That wouldn't occur to me in a dream.

[lbo]

Sometimes users might think that IMatch detected an external rename even if it did not. Consider the following example:

   
• Rename a file A.jpg that is a version of some other file (A.RAW) to A1.jpg (outside of IMatch).
• IMatch might think "Oh, A.jpg was deleted. And a new file A1.jpg has appeared".

correct, but just to avoid misunderstandings: There is no need to convince me not to do external renames.

My point is that a running IMatch usually does detect this rename correctly and "relocate" the file automatically.

Some users will notice this behavior and then use it regularly unless they know that the underlying mechanism is unreliable.

[Mario]

There are at least 10 places in the Help System where it says "DO NOT MOVE OR RENAME FILES OUTSIDE OF IMATCH. We mean it! For good reasons!!". With colors. And in extra boxes.
If a user still renames files outside of IMatch (usually, when IMatch is not running), they'll have to learn the hard way what the Relocate command is for.

There are limits of what I can do.
For example, 80% of the users (from telemetry) disable the friendly popup warning messages IMatch shows when certain important things happen.
And then they forget about it and the next time they use the function they may make a mistake.
But since they have disabled ("Do not show again") the warning message, IMatch cannot remind them.

That's just how it is. You cannot prevent the user from shooting himself in the foot if (s)he really wants to.

I cannot tell you how often I reply to a support request with a link to the Help system (after using the search function in the help myself).
And then I get back "Oh, I didn't know about this. I didn't know there is a help system...".
(Especially from users who have been trained to use mobile apps).

[Carlo Didier]

... users who have been trained to use mobile apps ...

What training?