File Export Errors

[Darius1968]

This log file is about a short session, in which I tried to copy 74 files - belonging to a category - to a folder - unindexed in IMatch - on my desktop.  53/74 files successfully copied over.  The remainder were flagged with errors, in an after-precedure-report, by IMatch.  IMO, this has to have something to do with folder/file naming convention, but what are the specifics? 

[Mario]

I see no problems in this log.
Just IMatch logging that is is not indexing a specific folder (because you batch processed the files outside of folders managed by IMatch).

[Darius1968]

I can see and appreciate that there were no disruptions to the standard operating procedures, while I was using the Batch Processor to copy over the files, but nonetheless, there were files that would/could not be copied, and this scenario is repeatable, given the same files, with the same destination for their copies.  So, what could be wrong? 

[Mario]

As I said, no warnings or errors about files not being copied in that log file.

[thrinn]

I see some very long path names in the log. Maybe you hit some 260 Byte length limit? According to this Microsoft article, this should not be a problem with a current Windows 10, as long as long path name support is activated on your system. But maybe it is worth to check if this could be a reason.

[Mario]

Usually IMatch reports a warning when a file copy, rename or move operation fails. And also tells the user in the Renamer results / BP UI.
The only warnings in the log file are about IMatch not indexing a folder (which is normal when the BP is used to put files outside of the IMatch database or the "Add to database" option is unchecked).

[lbo]

not contributing to solve Darius' problem but just a warning about long paths:

Maybe you hit some 260 Byte length limit? According to this Microsoft article, this should not be a problem with a current Windows 10

be aware that Perl doesn't handle long paths natively, therefore ExifTool might be unable to handle such files.

Last year I tried whether my ExifTool package could provide long path support, but even 64 bit Strawberry Perl and a launcher with longPathAware manifest didn't help, see https://exiftool.org/forum/index.php?topic=11034.0

[Mario]

A 260 characters path name should do for almost all purposes. I have never seen a need for longer path names, and most cross-platform toolkits and utilities do not support them anyway.
Best to keep things short and tidy.

[Darius1968]

I do have files in my DB that I've acquired from others, who have seen fit to use the file-name-part of the file, as a repository, for descriptive data that should have been embedded in the metadata, in the 1st-place! 

I should (at least, over time) take to renaming my files, to better comply with having more acceptable-length file names.  However, I don't want to outright get rid of the file names altogether, as they still provide useful information, rhat is still searchable, even in the presence of not having yet manually categorized!keyworded those files. 

If, indeed, problems are arising with 3rd-party faculties, within IMatch (ie., ExifTool), would importing the original file names into an attribute, before assigning new names solve the problem? 

[Mario]

I cannot tell. I do not see any errors in the log, and IMatch always logs when there is an issue with moving/renaming/copying files.