Delete without warnings

Further to my previous posting "Copy skip and log warnings" (no feedback on that one) :
Sometimes I delete a number of folders in 1 go.

I get warnings, like: File too long, or file is being accessed by another application (32), etc.

Filename too long, I found the solution not to make use of the Windows recycle bin, but file accessed by another applicaton ...
I have to click on continue and the file will still be deleted.

How to avoid these warnings?

I have disabled allmost all applications, but still I get these warnings.

==

Do you want to skip those files without showing the warning, or are you asking how to avoid the situation that causes the warning?

If you want to avoid the situation where a file is in use, you have to work out which application is using the file.

It can be Opus itself that's using the file, e.g. if a thread is trying to generate a thumbnail of a file and is taking a long time, or even locked-up, due to things like buggy video codecs.

You can usually use Process Explorer to find out which program(s) have a file in use. Run it (with UAC elevation if on Vista/7) and then use Find -> Find Handle or DLL from the menu, and type the name of the file that's in use.

My understanding is that the file/s might be in use as DOpus is indexing the size or whatever. Instal 'unlocker' or a similar right-click shell extension. If you don't want to do that switching to 'List' view should defeat the indexing function.

In that case : skip the files that are causing the 'warnings'.
I want to perform a delete action but donot want to sit behind my pc the whole time to click on retry or skip. If by the end of the job some files are still
there, then I can delete them separately.
Recently I had a few occassions that I had to delete hundreds of GBs, pretty annoying having to click on retry every 5-10 minutes.
Same goes with my other posting 'Copy, skip and log warnings'.

Donot know what else I might have to (un)tag

Does this not require you to keep sitting behind your pc so the file(s) can be unlocked, once DO gets you this warning?

It would be great if there would be a kind of option within DO like

Unlock Open/Locked files before deleting

=

Yes it does, but you can 'unlock' a folder before deleting it. Unlocker will at least show you which process is using the files.

Unlocking file handles should be done as a last resort. It can lead to problems. It's best to find out which program has the files open and get it to close them (or exit the program).

As for skipping warnings/errors, the QUIET argument to the delete command will do that. Try this command:

Delete NORECYCLE QUIET FORCE

Thanks, I'll try this out and get back on it.

I agree that unlocking is a last resort only.
The proposed unlocking feature wud be an option only, so users have to decide for themselves and take the responsibility of their action.

Or, it may be available in the below example as an additional parameter, being a more expert option, so to say,
Or, the delete process should continue, whilst skipping the locked files (now it halts), in the end notifying the user what files have been skipped.

Later...
I think this is quite a good solution. The delete stopped at 1 point only where files were locked.
The delete command wud read
Delete NORECYCLE SKIPLOCKED QUIET FORCE

Maybe in the next update...??

==

AFAIK, QUIET should already skip locked files.

Either way, if you want to request new behaviour, you need to drop GPSoftware a feature request.

I checked again, in my case, there were 2 locked files and delete halted. The files are 'guarded' by another application, i had to disable the 'guard' function temporarily.
Then they can be deleted.
Unlocking (using LockHunter) is impossible: "No any processes locking this file or folder have been found".
These are indeed the only files that are interrupting the delete process.

By the way is there also such kind of copy command that skips warnings..??
See Copy skip and log warnings

Many thanks sofar!!

The Copy command's WHENEXISTS argument takes care of most warnings, though not all.