You are viewing limited content. For full access, please sign in.

Question

Question

Task Migrate Entries does not delete original files

asked on September 10, 2015 Show version history

I am using the following versions of LaserFiche to try and perform the Task Migrate Entries:

 

LaserFiche Client 9.2.0.472 on a Windows 7 64-bit computer.

LaserFiche Server 9.2.0 on a Windows Server 2012 R2 server.

 

The problem & what I know: One of my volumes is full, and to continue using it as the main scanning location I need to free up space.  When I use the Task - Migrate Entries to move files from one volume to another it does not remove the files from the originating volume.  It use to do this Task just fine less than a week ago.  No updates have taken place to my client or server install.  The volume in question has 0 bytes of available space which has not caused a problem in the past when I used the Migrate Entries Task.  The volumes are on separate partitions.

 

What I have found out so far with testing:

- I have confirmed that the Task does move the files to the new volume and they are accessible.  

- LaserFiche recognizes the new location when I search the migrated files after the Task is completed.

- The originating files are still functional but LaserFiche does not see them.

- The Volume Consistency Checker does not accept my username and password so I cannot make use of its functions.

- A reboot of both the LaserFiche server computer and the repository computer does not offer any resolution.

 

Question: how can I get the Volume Consistency Checker to work, OR how can I get the Migrate Entries Task to work properly?!

 

Please help!  I have an entire practice that needs to keep up with scanning and I am crippled by this.

 

Thank you in advance for any help that you can offer!!!

0 0

Answer

SELECTED ANSWER
replied on September 10, 2015

Error 5 is access denied, looks like the LF server doesn't have write access.

0 0

Replies

replied on September 10, 2015

The LF server cleans up the files in the old volume in a background task that runs every 15 minutes. The event log might have more information about what is going wrong. If not, please open a support case so we can troubleshoot the issue.

0 0
replied on October 18, 2017 Show version history

I'm experiencing the same issue.  I've run migrate entries to move volumes.  The entries show up in the new volume but never get removed from the original.   I'd been running migrates for a while before I knew that this was an issue. Now I have hundreds of thousands of orphaned documents.  I don't know how to clean up this mess. 

I don't see any relevant errors in any logs that I can find.

0 0
replied on September 10, 2015

I do not know where to check the event viewer, but I can confirm that it is not cleaning up the old files.  Can you please let me know where to check the event viewer?  I did a migration of 20,000+ entries Tuesday and it still has not cleaned up any of the files.  

0 0
replied on September 10, 2015

Look in the Application log for events with the source LFS.

0 0
replied on September 10, 2015

I am getting an error that states the following on the LaserFiche server Event Viewer:

Error deleting a document page part volume data file.  Volume ID: 1 Store ID: 000B875E Path: \\servername\volume1\images\lfwdb001\images\00\0B\87\000B875E.LOC Error: 5

Any ideas?

 

Thanks!

0 0
replied on September 10, 2015

That is odd considering nothing in the setup has changed.  Is there any way to find more details about the access violation or what credentials it is trying to authenticate with?

 

Thanks for your help.

0 0
replied on September 10, 2015

View the properties for the Laserfiche Server service to see which user it is running as. Alternatively you can use the task manager or Process Explorer to see the user for lfs.exe.

0 0
replied on September 14, 2015

After viewing the Application logs in the Event Viewer I saw repetitive errors coming from source LFS.  The majority of them were Error 5 which I am told is related to read/write access.  After applying full read/write permissions to the 'Everyone' group on the share in question LF was able to clean up behind itself.  It even remembered the migrations I did multiple days ago and cleaned up after them once it had the right access.

 

I have no idea how/why the permissions on that share changed considering we have ben using it for over 6 years... but that is something I can figure out later.

 

Thank you very much for your prompt assistance Robert.

 

 

0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.