File Explorer "The action can't be completed because the folder/file is open in another program"

WHICH PROGRAM?!

On Fri, 27 Dec 2013 20:45:40 +0000 (UTC), John Doe
wrote:


WHICH PROGRAM?!

(S)WAG: close cloud!

Per John Doe:
WHICH PROGRAM?!

Don't you just *love* it when Windows throws a notification like that?
"Something's wrong, we probably know exactly what... but we're going to
let you figure it out..."
--
Pete Cresswell

(PeteCresswell) wrote:
Per John Doe:
WHICH PROGRAM?!

Don't you just *love* it when Windows throws a notification like that?
"Something's wrong, we probably know exactly what... but we're going to
let you figure it out..."

That's a tradition in computing.

In Windows, a third-party program like Sysinternals
Handle or Sysinternals Process Explorer, may help you figure it out.
But the issue is far from "user friendly".

http://technet.microsoft.com/en-us/s...rnals/bb896653

Unix had the same tradition. Some of the programs listed
here, were some of the first things I added to my Unix
box at work. Because it sported the same annoying issue.
The worst on boxes like that, was when the CD tray wouldn't
open, because the CD would not dismount, and all because
some "file was open".

http://en.wikipedia.org/wiki/Lsof

Somewhere in my travels, I've seen an OS that *did* list
open handles on a file, without teasing you. But I can't
remember exactly where I saw that now.

Paul

(PeteCresswell) posted this via
:

Per John Doe:
WHICH PROGRAM?!

Don't you just *love* it when Windows throws a notification like that?
"Something's wrong, we probably know exactly what... but we're going to
let you figure it out..."

You're right of course. Like in task manager, you should be able to hover
over the process and get a path balloon... same with PID, you should be
able to hover over that and identify the dependenc[y][ies] because if the
system can display the end of the string, it certainly had to obtain that
from the path - and it'd be a small matter of a tiny piece of code to
acomplish the complete picture. Apparently the millionaires who design
these operating systems don't bother to use them... At some level they
even insulate themselves from any meaningful feedback for sure.

Sometimes you just have a picture or text file still open in the folder...

Sometimes a 3rd party process kept a handle open even though you've closed
it...

2 freewares that I ocassionally use are "Unlocker" and/or "LockHunter".

http://www.emptyloop.com/unlocker/

http://lockhunter.com/

It's just easier than trying to change Microsoft's mind[s].

--

I AM Bucky Breeder, (*(^;
and my only New Year Resolution is:

to totally focus on my inner "AWESOMENESS!"
(Because I'm not entirely comfortable with
the words "Hero;" "Genius;" and "Legendary.")

http://tinyurl.com/7fude4d

On 29 Dec 2013 15:30:39 GMT, "Bucky \"Wurk Arownd\" Breeder"
wrote:

(PeteCresswell) posted this via
:

Per John Doe:
WHICH PROGRAM?!

Don't you just *love* it when Windows throws a notification like that?
"Something's wrong, we probably know exactly what... but we're going to
let you figure it out..."

You're right of course. Like in task manager, you should be able to hover
over the process and get a path balloon... same with PID, you should be
able to hover over that and identify the dependenc[y][ies] because if the
system can display the end of the string, it certainly had to obtain that
from the path - and it'd be a small matter of a tiny piece of code to
acomplish the complete picture. Apparently the millionaires who design
these operating systems don't bother to use them... At some level they
even insulate themselves from any meaningful feedback for sure.

Sometimes you just have a picture or text file still open in the folder...

Sometimes a 3rd party process kept a handle open even though you've closed
it...

2 freewares that I ocassionally use are "Unlocker" and/or "LockHunter".

http://www.emptyloop.com/unlocker/

http://lockhunter.com/

It's just easier than trying to change Microsoft's mind[s].

In my youth, I'm now 75, IBM recognized the problem and required all
programs to surface a code for all errors. This added to the
development time, especially developing the test cases, and management
blamed this work for missed schedules. Few liked to do this so it was
an easy sell to just let it slip with each subsequent program cycle.
The biggest reason for most poor quality is management inexperience
and willingness to agree to whatever higher management wants.

Glenn wrote:
On 29 Dec 2013 15:30:39 GMT, "Bucky \"Wurk Arownd\" Breeder"
wrote:

(PeteCresswell) posted this via
:

Per John Doe:
WHICH PROGRAM?!
Don't you just *love* it when Windows throws a notification like that?
"Something's wrong, we probably know exactly what... but we're going to
let you figure it out..."
You're right of course. Like in task manager, you should be able to hover
over the process and get a path balloon... same with PID, you should be
able to hover over that and identify the dependenc[y][ies] because if the
system can display the end of the string, it certainly had to obtain that
from the path - and it'd be a small matter of a tiny piece of code to
acomplish the complete picture. Apparently the millionaires who design
these operating systems don't bother to use them... At some level they
even insulate themselves from any meaningful feedback for sure.

Sometimes you just have a picture or text file still open in the folder...

Sometimes a 3rd party process kept a handle open even though you've closed
it...

2 freewares that I ocassionally use are "Unlocker" and/or "LockHunter".

http://www.emptyloop.com/unlocker/

http://lockhunter.com/

It's just easier than trying to change Microsoft's mind[s].

In my youth, I'm now 75, IBM recognized the problem and required all
programs to surface a code for all errors. This added to the
development time, especially developing the test cases, and management
blamed this work for missed schedules. Few liked to do this so it was
an easy sell to just let it slip with each subsequent program cycle.
The biggest reason for most poor quality is management inexperience
and willingness to agree to whatever higher management wants.

Actually, there are good reasons for the hesitancy to solve
this particular problem (handle owned by another program).

The developers are worried, about a scenario where more
than one person uses a single computer. Perhaps two people
time share a computer, and the hard drive has the files of
two users present. Or the other scenario, is a time-shared
Unix box, where multiple terminals host multiple users, all
running programs at the same time.

The issue is, how much info do you want to show, about
what another user is doing.

This concern has caused no end of problems. It's why
Linux is missing a useful performance graph in one
of its performance displays. And why projects
such as "iotop" **** and moan when you run them.
Even back when I was using programs like lsof or
pff, the README would whine about the difficulty
in deciding whether it would always have to be
run as root, whether it should be showing
other people's activities and so on.

Even the search programs, such as Linux "locate",
worry about showing the file names, of another
users files.

If it wasn't for that, and desktop systems were single user
and single account only, we might actually have
useful error messages concerning handles by now.

Paul

Per Bucky "Wurk Arownd" Breeder:
You're right of course. Like in task manager, you should be able to hover
over the process and get a path balloon... same with PID, you should be
able to hover over that and identify the dependenc[y][ies] because if the
system can display the end of the string, it certainly had to obtain that
from the path - and it'd be a small matter of a tiny piece of code to
acomplish the complete picture. Apparently the millionaires who design
these operating systems don't bother to use them... At some level they
even insulate themselves from any meaningful feedback for sure.

Yet they spend all that effort moving the furniture around with each new
release...... -)
--
Pete Cresswell