Error when moving files

I often get an error when moving files.

Always the deletion of a directory is not possible. I can delete it manually after the message appeared without problems. The dirs are always empty, the files that were in before have always been moved. I have admin rights and also no file/dirs are in use.

I get this error-message on different PC's since v9.0.0.? and there's no difference if I move files/dirs between network or local.

The below picture is German, translation is "An error occured while moving.... (zero)"

In this example I only moved one directory with one file in it (a Symantec Ghost-Image created in DOS-mode). The file has been moved, the dir not.

Does clicking Retry make the operation work?

My bet is that either anti-virus software or a handler for the .GHO images (e.g. so you can double-click them and view inside of them) is being triggered when Opus reads the files and it is getting in the way of the move (e.g. by holding a lock on that directory).

I have seen similar problems with True Image backup files on Vista in both Opus and Explorer, for what it's worth. Not sure of the exact cause as I didn't investigate it further (I don't move them around much and it wasn't Opus-specific so I didn't feel like spending time on it).

If your problem only happens in Opus, and not Explorer, and if clicking Retry succeeds then maybe the answer is for Opus to automatically wait a moment and retry before displaying the error message. (Maybe Explorer already does that. It does similar things in a number of other places.)

Does the problem happen for you in Explorer?

Retry doesn't help.

The Ghost-Image was just an example. I have no AV or Ghost etc. installed. The Ghost-image was, as I wrote, created in DOS-Mode. The error also occurs on other files that were defintely NOT open by any app/progress. Also I wrote, that the files always have been successfully moved and I can always delete the empty directory after canceling the error-message. So the problem is that DO can't delete the directories..

It's like DO tries to delete the folder before the file-deletion (after copying) has been finished. I don't know the meaning of "Null" (zero) in the message window. I filled out a request to GP.

I never use Explorer (Vista, brrrr!!!!) and this error isn't reproducable - but I'll do some testing.

Try disabling viewer plugins as well.

It's possible that a plugin is still trying to generate information about the files (e.g. for the Description column) after they have been moved, which would often keep a lock on the directory. If the files are being moved around on the same partition then you wouldn't get an error for the files themselves since they can be moved (renamed) while something (a plugin) is reading them.

If a plugin (or video codec or similar being called by a plugin) decides it's going to read through the whole file to see if it understands it then it might make sense for this problem to appear with ghost backups as they're big files. If it is that then we should work out which plugin/codec/etc. is going wrong.

I could reproduce the problem with copying the same folder again back.

As it can't be a file-related error like locked files (100% no codec, plugin, etc. running), I deleted the folder, created a new folder with same name, put file in again and it worked.

So it might be a security-prob (but I never change any rights and use standard system settings)?

Nevertheless I asked GP to tell me what "null" (zero) could mean in this case.

It is possible that a plugin/codec still has a lock on the directory even after the files in it have been moved, but it might not be that.

I thought of a couple of other things which might be related to the problem. They are probably irrelevant but here they are in case they help track down what's wrog:

Are there descript.ion file descriptions in the directory you are moving?

Is the Copy Filter enabled? (Settings -> Copy Filter)

Hello Nudel,

no descript.ion, no filter, just simple move. What makes me wonder is that I always can delete/move the empty folder after the error-message without any probs.

Unfortunately Dr. Perry mailed me that "null" is a Windows-message that means all and nothing!

I'll report when this error occures again. I believe it's a NTFS-rights-related problem, so I'll check the rights of a folder if it won't be moved in future (alltough I usually don't change the folderrights).

Try running Process Monitor and see which operations are being done on the folder. It might reveal what is failing and also the exact order of any other operations that are done on the same folder or the files within in.

Same problem here. Wanted to move a number of folders having big .vob-files, from my HD to an external firewire drive.
That wud take a long time, so I had DO move the files overnight. Next morning there was this error and I cancelled the job.

Lateron the day again, whilst moving two folders, total 13GB: DO halted.

This is not a default error, because I just moved 2 other folders of approx. the same size : no problems.

Did not try it, how about 'Copy' instead of Move??
Wonder whether that wud get me the same error...

mrwul, The same "Null" error that Sasa mentioned, or some other error message?

Have either of you tried Process Monitor like I suggested?

Frankly, I donot know... :blush:
Cud it be window saying [Abort] [Retry] [Cancel] [Ignore] ?
Anyway, I stopped it.

I have done two 'copy jobs', without errors, one job was 80GB.

Will give it a try again and see what happens overnight.

Process Monitor - huh... ?
Is that within DO ?
Sorry .. doesn't ring a bell.


Process Monitor is a Sysinternals (now Microsoft) utility... googling for it should find it pretty easy.

Okay.. Well, the error occurred twice in the scenario of moving BIG files (1GB) in large volumes (say 40-60GB) from HD to an external
firewire drive. Normally I donot get such errors.

Since then I used to copy the files and in -say- half a dozen times I copied to external drive and to other partitions on other internal HD's
around 250GB without errors.

Drawback: this only leads to some extra work in checking and selecting the files that have been copied, so they can be deleted.
I.e. the files should first be copied into a special folder, so you can more easily see what has been copied, etc.
On the other hand: it is saver (I found out - when the dest.disc was full)

Ah well... :wink:

Without knowing what the error message was it's impossible to say whether it was a real/justified error or a bug.

The "(null)" error message in Sasa's screenshot is definitely odd (although it could be due to the system returning an error number with no matching error description, or something similar), but just getting an error when copying files isn't necessarily odd and may just mean there was an actual error.

This error (Null) still occurs on differnet computers with different versions of DO9 till newest.

I found out that this error occurs on protected folders when moving files (folder is always empty and not deleted), but also when only copying (?).

Well, today I did a copy of 6 folders, total around 37-38GB and got the 'error' again. This time I saved it. Note when clicking on skip, again the same error, had to click 3x on skip and copying proceeded (it stopped halfway)

It says: file or folder is damaged and unreadable (1392)

That looks like a DVD. Are you copying directly off of a DVD? A copy-protected DVD? (Edit: Ignore that, I re-read and see you're copying from a HD.)

Does exact same copy work in other programs?

Did you try clicking Retry on any of the errors? If so what happened?

Can you repeat the errors while Process Monitor is running to see what exactly is failing?

What's the size, in bytes, of the file(s) which failed?

Retry: same error.
Files were 1GB in size. But frankly, when copying a lot of 1GB files, I cannot reproduce which one of the files resulted in this error.

Normally there is no problem in copying files, only mass copy (move) is getting this error.

Will give it a try again...
hv started what's running.

Please try a copy in Explorer as well to check that the error only happens in Opus.

Running chkdsk on the source and destination drives is probably a good idea as well. The drives could be failing and having intermittent read/write errors, e.g. when hot after copying a lot of data.

Yesterday I copied abt 27GB to the external drive. It went fine.
The copy of the folder that initially was 'damaged' went fine.
The drive is new, by the way. I just wanted to free up space from internal drives to the external drive.

I donot think it has something to do with the drive being an external one, as the first errors was from one internal RAID drive to another one.
At the time it was a move, this time a copy.

Copying/move small volumes: no problem, so I can only 'test' it when copying 25-30 or GB. Such volumes you donot copy/move just 'for fun' and see what happens,i.e. I hv such a job done overnight, or when watching tv, else it takes too much sources.

Maybe i will give it another try, later.