# Move-SCU fails even after succesful Store-SCP of same study
**URL:** https://discourse.orthanc-server.org/t/move-scu-fails-even-after-succesful-store-scp-of-same-study/1380
**Category:** Google Groups archive
**Created:** [March 15, 2019, 6:05pm UTC](https://discourse.orthanc-server.org/t/move-scu-fails-even-after-succesful-store-scp-of-same-study/1380 "2019-03-15T18:05:43Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@Jonathan\_salas](https://discourse.orthanc-server.org/u/Jonathan_salas)
#### Post date: [March 15, 2019, 6:05pm UTC](https://discourse.orthanc-server.org/t/move-scu-fails-even-after-succesful-store-scp-of-same-study/1380/1 "2019-03-15T18:05:43Z")
I have generated --verbose logs and attached them above along with the configuration file.
I am using Orthanc to interface with Biosense Webster CARTO3 software and they are connected to each other via a network switch. All communication happens with the default port.
I am having isolated instances where restoring a study from the Orthanc server to the PACS workstation fails even after a successful storage onto the server. I have generated 4 --verbose logs which each represent an attempt and is explained in the README.txt file. In the first attempt, I tried to restore a study from the server and received the following error on the Orthanc side:
`
E0315 12:05:47.882938 OrthancException.h:85] The specified path does not point to a regular file: The path does not point to a regular file: C:\Active Study Data\TRANSEPPACS-A\0e\7e\0e7eb045-4e65-492f-a40b-f03f1ff4fef1
E0315 12:05:47.882938 MoveScp.cpp:237] IMoveRequestHandler Failed: The specified path does not point to a regular file
`
On the PACS side my output is:
`
[RestoreService] - Dicom Status Code = ‘C000’ - Biosense Status = DicomUnknownResponse. Restore read response: Unmapped error
C\_MOVE operation did not complete successfully (error = 49152). Aborting Storage SCP connection
Error handling C-MOVE operation
`
I am having similar errors with other studies but this is inconsistent. Any advice on how to proceed would be GREATLY appreciated.
[1-restore fail 027\_2019.log](https://discourse.orthanc-server.org/uploads/short-url/fFFzt3S3qbc9l4fbn1uKpyPmYjU.log) (14.9 KB)
[2-backup success 027\_2019.log](https://discourse.orthanc-server.org/uploads/short-url/cEaauHmdkbdTsAgQJKZIyXNGyZZ.log) (5.9 KB)
[3-restore fail 027\_2019.log](https://discourse.orthanc-server.org/uploads/short-url/9PZ74ZKFvh5RGl3IoU3vgI3mZOE.log) (9.63 KB)
[4-reboot and restore fail 027\_2019.log](https://discourse.orthanc-server.org/uploads/short-url/ua3hJwh0vMyBkNZGfcxOwz0wU8v.log) (9.63 KB)
[orthanc.json](https://discourse.orthanc-server.org/uploads/short-url/gr1aHHwzZOvMHOkF4PWnxwFVJ9A.json) (17.9 KB)
[README.txt](https://discourse.orthanc-server.org/uploads/short-url/84OXB31YeDabMczj2PMOAfDjo8b.txt) (467 Bytes)
---
### Author:  [@Jonathan\_salas](https://discourse.orthanc-server.org/u/Jonathan_salas)
#### Post date: [March 15, 2019, 6:08pm UTC](https://discourse.orthanc-server.org/t/move-scu-fails-even-after-succesful-store-scp-of-same-study/1380/2 "2019-03-15T18:08:03Z")
In attempt 2, I succesfully stored the study to the server. In attempt 3 I attempted to restore that file and got the same error as in attempt 1. In attempt 4, I reboot the CARTO3 workstation and try to restore again from scratch only to land back at the outputs from instance 1.
---
### Author:  [@Alain\_Mazy3](https://discourse.orthanc-server.org/u/Alain_Mazy3)
#### Post date: [March 18, 2019, 4:15pm UTC](https://discourse.orthanc-server.org/t/move-scu-fails-even-after-succesful-store-scp-of-same-study/1380/3 "2019-03-18T16:15:58Z")
Since you have that error:
The path does not point to a regular file: C:\Active Study Data\TRANSEPPACS-A\0e\7e\0e7eb045-4e65-492f-a40b-f03f1ff4fef1
could you tell us if the given file is there ? Is it accessible ?
If the file is not there, and the instance still exists in the database, I would say that “someone/something” deleted the file…
FYI, it might be interesting to read this section of the doc: [http://book.orthanc-server.com/faq/orthanc-storage.html](http://book.orthanc-server.com/faq/orthanc-storage.html)
---
### Author:  [@Jonathan\_salas](https://discourse.orthanc-server.org/u/Jonathan_salas)
#### Post date: [March 18, 2019, 5:58pm UTC](https://discourse.orthanc-server.org/t/move-scu-fails-even-after-succesful-store-scp-of-same-study/1380/4 "2019-03-18T17:58:51Z")
The file is not there nor is it created when I store to the server but nonetheless asks for it when I go to restore.
The only interaction I have with the storage folder is that using “FreeFileSync” I have it set so that the contents of the storage folder are mirrored over to an archive on a different disk. Going through the sync logs and FreeFileSync’s garbage can I can confirm that files are only being pushed one way (see attached screenshot) and that the only thing being “deleted” and then replaced is 3 files:
- index
- index-shm
- index-wal
Here is what a standard log looks like:
`
Enter code here\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
> 3/15/2019 TRANSEPPACS-A One-Way Update to Archive
>
> Completed successfully
> Items processed: 7 (45.3 MB)
> Total time: 00:04:03
>
> * * *
[1:02:11 PM] Info: Comparison finished: 5,342 items found
[1:06:14 PM] Info: Synchronizing folder pair: Update\>
C:\Active Study Data\TRANSEPPACS-A
E:\PACS Backups\TRANSEPPACS-A Raw Data
[1:06:14 PM] Info: Updating file “E:\PACS Backups\TRANSEPPACS-A Raw Data\index”
[1:06:14 PM] Info: Updating file “E:\PACS Backups\TRANSEPPACS-A Raw Data\index-shm”
[1:06:14 PM] Info: Updating file “E:\PACS Backups\TRANSEPPACS-A Raw Data\index-wal”
[1:06:14 PM] Info: Creating folder “E:\PACS Backups\TRANSEPPACS-A Raw Data\bd\0b”
[1:06:14 PM] Info: Creating folder “E:\PACS Backups\TRANSEPPACS-A Raw Data\fa\6d”
[1:06:14 PM] Info: Creating file “E:\PACS Backups\TRANSEPPACS-A Raw Data\bd\0b\bd0b234b-831d-48b3-a87e-3dd15ebb8c6f”
[1:06:14 PM] Info: Creating file “E:\PACS Backups\TRANSEPPACS-A Raw Data\fa\6d\fa6db637-79b0-4f17-81b4-251598d3066b”
…
`
---
### Author:  [@Jonathan\_salas](https://discourse.orthanc-server.org/u/Jonathan_salas)
#### Post date: [March 18, 2019, 5:59pm UTC](https://discourse.orthanc-server.org/t/move-scu-fails-even-after-succesful-store-scp-of-same-study/1380/5 "2019-03-18T17:59:44Z")
Here is the screenshot with my “FreeFileSync” settings as well
---
### Author:  [@jodogne](https://discourse.orthanc-server.org/u/jodogne)
#### Post date: [March 18, 2019, 6:27pm UTC](https://discourse.orthanc-server.org/t/move-scu-fails-even-after-succesful-store-scp-of-same-study/1380/6 "2019-03-18T18:27:37Z")
Your database is visibly corrupted because you have not stopped Orthanc before running the backup, as documented in the Orthanc Book:
[http://book.orthanc-server.com/users/backup.html](http://book.orthanc-server.com/users/backup.html)
---
### Author:  [@Jonathan\_salas](https://discourse.orthanc-server.org/u/Jonathan_salas)
#### Post date: [March 18, 2019, 6:31pm UTC](https://discourse.orthanc-server.org/t/move-scu-fails-even-after-succesful-store-scp-of-same-study/1380/7 "2019-03-18T18:31:37Z")
Okay so I have stopped running the backup software and will ensure to stop Orthanc before I try that again.
How should I proceed so that I can successfully restore these files?
-JS
---
### Author:  [@Alain\_Mazy3](https://discourse.orthanc-server.org/u/Alain_Mazy3)
#### Post date: [March 19, 2019, 10:40am UTC](https://discourse.orthanc-server.org/t/move-scu-fails-even-after-succesful-store-scp-of-same-study/1380/8 "2019-03-19T10:40:04Z")
If the files are not there anymore, you should re-import them by uploading them through the web interface or pushing them through DICOM protocol.
---
### Author:  [@Jonathan\_salas](https://discourse.orthanc-server.org/u/Jonathan_salas)
#### Post date: [March 19, 2019, 12:28pm UTC](https://discourse.orthanc-server.org/t/move-scu-fails-even-after-succesful-store-scp-of-same-study/1380/9 "2019-03-19T12:28:01Z")
Importing the files through the DICOM protocol doesn’t create the file that is being requested upon retrieval.
I also can not import the files through the web interface because when CARTO3 software exports files to USB, it doesn’t export them as .DCM files but rather a format that can only be retrieved by interfacing with another CARTO workstation.
I should have a copy of all of the files that were uploaded to Orthanc, I just wonder how the best way to rebuild my corrupted database at this point?
---
### Author:  [@Jonathan\_salas](https://discourse.orthanc-server.org/u/Jonathan_salas)
#### Post date: [March 19, 2019, 12:29pm UTC](https://discourse.orthanc-server.org/t/move-scu-fails-even-after-succesful-store-scp-of-same-study/1380/10 "2019-03-19T12:29:04Z")
If you look at attachment 2 and attachment 3 above you’ll see the verbose logs for re-importing (2) and then failed subsequent retrieval (3) of the files.
---
### Author:  [@Alain\_Mazy3](https://discourse.orthanc-server.org/u/Alain_Mazy3)
#### Post date: [March 19, 2019, 1:48pm UTC](https://discourse.orthanc-server.org/t/move-scu-fails-even-after-succesful-store-scp-of-same-study/1380/11 "2019-03-19T13:48:00Z")
Since your DB/Storage is corrupted, you can
- either restore a working backup of the full DB and all files (OrthancStorage directory)
- or you can erase the OrthancStorage directory and then re-import everything the same way as you imported it the first time.
---
### Author:  [@Alain\_Mazy3](https://discourse.orthanc-server.org/u/Alain_Mazy3)
#### Post date: [March 19, 2019, 1:51pm UTC](https://discourse.orthanc-server.org/t/move-scu-fails-even-after-succesful-store-scp-of-same-study/1380/12 "2019-03-19T13:51:57Z")
Checking the subject of your request, settings this flag to true in the config file might solve your particular problem but there’s really no guarantee … and your DB/Storage might still be corrupted at other places
```auto
// Specifies how Orthanc reacts when it receives a DICOM instance
// whose SOPInstanceUID is already stored. If set to "true", the new
// instance replaces the old one. If set to "false", the new
// instance is discarded and the old one is kept. Up to Orthanc
// 1.4.1, the implicit behavior corresponded to "false".
"OverwriteInstances" : false,
```
```auto
from [https://bitbucket.org/sjodogne/orthanc/raw/Orthanc-1.5.6/Resources/Configuration.json](https://bitbucket.org/sjodogne/orthanc/raw/Orthanc-1.5.6/Resources/Configuration.json)
```
```auto
```
```auto
```
---
### Author:  [@Jonathan\_salas](https://discourse.orthanc-server.org/u/Jonathan_salas)
#### Post date: [March 20, 2019, 7:09pm UTC](https://discourse.orthanc-server.org/t/move-scu-fails-even-after-succesful-store-scp-of-same-study/1380/13 "2019-03-20T19:09:00Z")
I have decided to rebuild the database from scratch so as to avoid any other corruption issues. Thank you for all the support.
My question now is whether Windows 7 “Backup and Restore” will corrupt the DB as well if the storage directory is flagged as a part of the folders included in the backup?
---
### Author:  [@Jonathan\_salas](https://discourse.orthanc-server.org/u/Jonathan_salas)
#### Post date: [March 20, 2019, 7:09pm UTC](https://discourse.orthanc-server.org/t/move-scu-fails-even-after-succesful-store-scp-of-same-study/1380/14 "2019-03-20T19:09:43Z")
Also, can you please explain why I would want the overwrite flag set to “false” by default?
---
### Author:  [@Alain\_Mazy3](https://discourse.orthanc-server.org/u/Alain_Mazy3)
#### Post date: [March 21, 2019, 8:06am UTC](https://discourse.orthanc-server.org/t/move-scu-fails-even-after-succesful-store-scp-of-same-study/1380/15 "2019-03-21T08:06:46Z")
I guess “Backup and Restore” might corrupt the SQLite DB as well.
If you want to perform “live backup”, you might want to switch to a PostgreSQL DB.
Another option might be to have another Orthanc running on another PC and implement [autorouting](http://book.orthanc-server.com/users/lua.html?highlight=lua#auto-routing-of-dicom-images)to copy every instance received on the main Orthanc to the backup one.
---
### Author:  [@Alain\_Mazy3](https://discourse.orthanc-server.org/u/Alain_Mazy3)
#### Post date: [March 21, 2019, 8:14am UTC](https://discourse.orthanc-server.org/t/move-scu-fails-even-after-succesful-store-scp-of-same-study/1380/16 "2019-03-21T08:14:10Z")
Actually, when handling valid DICOM files, you’re not supposed to need that overwrite flag set to “true”. Since DICOM files are supposed to be immutable, if you upload a DICOM file a second time, Orthanc will check that it already has this file (mainly based on the SOPInstanceUID).
And, files are not supposed to disappear so no need to overwrite…
However, having this configuration set to “true” is always a good choice (we just set the default value to “false” to keep the backward compatibility).
Enabling overwrite was mainly introduced for guys who are changing the compression inside DICOM files to minimize disk usage. In this case, they will upload the same instance a second time and they want the recompressed instance to replace the previous file.
---
### Author:  [@Jonathan\_salas](https://discourse.orthanc-server.org/u/Jonathan_salas)
#### Post date: [March 21, 2019, 12:19pm UTC](https://discourse.orthanc-server.org/t/move-scu-fails-even-after-succesful-store-scp-of-same-study/1380/17 "2019-03-21T12:19:00Z")
Now that I think of it, are there any other windows features that should be turned off with respect to the storage folder?
What would happen if for example the storage folder inherits archiving, encryption, or indexing from it’s parent?
---
### Author:  [@Jonathan\_salas](https://discourse.orthanc-server.org/u/Jonathan_salas)
#### Post date: [March 21, 2019, 12:22pm UTC](https://discourse.orthanc-server.org/t/move-scu-fails-even-after-succesful-store-scp-of-same-study/1380/18 "2019-03-21T12:22:44Z")
With respect to the Overwrite flag:
In my situation we may restore the DICOM images to another CARTO workstations where we may edit it such as manually cleaning up the electroanatomical map generated and excluding data points. If we re-uploaded the same study with these modifications, what should our Overwrite flag be?
---
### Author:  [@Alain\_Mazy3](https://discourse.orthanc-server.org/u/Alain_Mazy3)
#### Post date: [March 21, 2019, 1:10pm UTC](https://discourse.orthanc-server.org/t/move-scu-fails-even-after-succesful-store-scp-of-same-study/1380/19 "2019-03-21T13:10:01Z")
then you would need Overwrite = true
---
### Author:  [@Jonathan\_salas](https://discourse.orthanc-server.org/u/Jonathan_salas)
#### Post date: [March 22, 2019, 5:20pm UTC](https://discourse.orthanc-server.org/t/move-scu-fails-even-after-succesful-store-scp-of-same-study/1380/20 "2019-03-22T17:20:46Z")
Thank you again for the continued support, our department has historically not had success gaining access to the hospital DICOM network and I’ll be the first to attempt to host their own.
With regards to the original issue, are there any other windows features that should be turned off with respect to the storage folder?
What would happen if for example the storage folder inherits archiving, encryption, or indexing from it’s parent?
[Next page](https://discourse.orthanc-server.org/t/move-scu-fails-even-after-succesful-store-scp-of-same-study/1380.md?page=2)