Windows 7 Taskforce

logic_earth wrote on January 29, 2009, 11:48am

Its not so easy to solve this problem, two I/O request trying to work on the same file/folder at once, something has to give. The OS treats them both as equal level processes as far as I know. Explorer is an application that sit atop the OS, its not the OS. ;)

When you get that message, Windows Explorer sent a request to work on those files/folder, but was denied by the OS saying they are locked because another application is using them. Windows Explorer doesn't control the thumbnailer, it only starts it up and retrieves the results.

So its not so simple as aborting the thumbnailer when another I/O job wants to work on the same files/folder, the thumbnailer was there first, the other request must wait in line.

And you can turn off thumbnails in Folder Settings.

poet wrote on January 29, 2009, 12:03pm

Sure, one has to give and in this case it should be the operation not initiated by the user. That's what I suggested as one solution. The process accessing "thumbs.db" should be sensitiv to this operation and abort on it's own.

"And you can turn off thumbnails in Folder Settings."
I didn't find any option to not save the thumbnails. If you mean disabling thumbnails altogether, that's not realy what I had in mind.
Also, while there is this "Always use icons,..." option, that's no even saying it won't create thumbnails anyway.

logic_earth wrote on January 29, 2009, 12:17pm

@poet, but the thumbnailer was initiated by the user, even tho its spawned from Windows Explorer, the OS doesn't see it that way. It sees two I/O jobs from the same user with the same weight when that happens it goes to first come first serve.

A process is never killed is mid-stream during its processing unless forced by an error or killed by the user. Each process is given a timelimit to complete if it doesn't its sent back inline for another turn. Aborting the thumbnailer is not an option, aborting it in mid-stream can cause data corruption.

As for "thumbs.db" unless I miss something Windows Vista/7 no longer do that they save the cache in a central location. I might be mistaken but I've not seen "thumbs.db" since Windows XP.

%LocalAppData%\Microsoft\Windows\Explorer

No easy solution to this problem.

poet wrote on January 29, 2009, 12:30pm

A) The thumbnail process is not initiated by the user, even if it runs with user priviliges. It was started by the system and runs in the background.

B) I didn't say the system should kill that process, I said that the thumbnail process should be sensitive and close down on it's own ... gracefully.

C) As you can see from the added image the "thumbs.db" is not my imagination ...

logic_earth wrote on January 29, 2009, 12:41pm

"A) The thumbnail process is not initiated by the user, even if it runs with user priviliges. It was started by the system and runs in the background"

No, it was started by Windows Explorer not the System. It was initiated by the user when you entered into the folder, your settings told Windows Explorer to start the thumbnailer when it encounters files it can handle. Its not set as a background process.

The move operation was started by Windows Explorer when initiated by the user. The OS (Windows) cannot tell the difference between these two processes, they have the same weight.

"B) I didn't say the system should kill that process, I said that the thumbnail process should be sensitive and close down on it's own ... gracefully."

It cannot because it (thumbnailer) is unaware of any other I/O jobs that are wanting to work on the same file/folder. It only knows about itself and its job no other. Other I/O jobs must wait for the thumbnailer to clear its locks on the files or wait for the locks to expire.

"C) As you can see from the added image the "thumbs.db" is not my imagination ..."

Never said it was, just that I have not seen one on Windows Vista or 7. Possible different settings to bring back "thumbs.db" I don't know for sure.

logic_earth wrote on January 29, 2009, 12:51pm

Microsoft devised an excellent solution to this problem as shown in the dialog. Can wait and "Try Again", "Skip" the locked file and continue on with the unlocked files, or "Cancel" the entire operation. Otherwise there is no solution to this problem in a technical way that doesn't have potential to corrupt data.

Previous to Windows Vista the entire process stopped only completing half of its job. It now completes its job minus the locked files. Much better then before I must say.

Ensign Joe wrote on January 29, 2009, 12:54pm

Explorer shouldn't copy that Thumbs.db shit file at all. It's just annoying. Especially if you copy a whole folder to FTP where this file is useless.
Also this file will be recreated if you open the destination folder anyway, so why bother copying it.

logic_earth wrote on January 29, 2009, 1:03pm

I'm going to guess but did these files come from a Windows XP data source?

"...although Vista does not [normally] use thumbs.db files it does have the capacity to see them and use them if they are there, and it will do so if you [inadvertently] copied them across from your XP machine."

So if you delete "thumbs.db" you should have less problems.

poet wrote on January 29, 2009, 1:44pm

Nop, not from XP.

And of course there are solutions to this problem. You just have to stop repeating yourself and start using some logic ... stop guessing and assuming, start thinking ...

logic_earth wrote on January 29, 2009, 1:49pm

Okay, poet, what is the solution? Pick one that actually will work too.

Also, is the drive a network drive?

poet wrote on January 29, 2009, 2:07pm

I've provided short solutions right from the start, but if you need a more "colorful" explanation, let's make this very, very simple follow ...

In this big warehouse there is this guy, let's call him "Browser", who talks to the client, processes his requests and also issues internal logistics tasks.
When he sees there have been changes he tells another guy, let's call him "Thumbnail Creator", to make nice little images of the contents of the boxes stored in this warehouse.
Now, if the client tells "Browser" to remove some of those boxes from the warehouse, "Browser" should check if "Thumbnail Creator" is currently working on those specific boxes and if so tell him to stop. After that is resolved "Browser" can freely tell yet another guy to trash those boxes.

Get it?

billerr wrote on January 29, 2009, 2:12pm

Agreed with poet here.

The thumbnailer process is of course treated as a same-level process as the file operation, they are indeed user-level operations. However, since both processes are designed by the same team, they should be aware of each other. It seems that the thumbnailer process which is meant to be a background process doesn't take into account foreground processes like the file operations. exactly as a Windows Update download adjusts it's speed to not hinder foreground download initiated by explicit user behavior.

Either the thumbnailer should listen for operations that conflict with its work, and pause or dtop altogether, or the file operation process should include handlers to stop the thumbnailer as a part of the copy/move/delete process. That would be intelligent. Instead of waiting for an uninitiated user to decide about a process he hasn't explicitly started. Background should be kept background.

logic_earth wrote on January 29, 2009, 2:29pm

Poet, you are assuming Windows Explorer and the Thumbnailer are working in a synchronous matter. This is not the case, they are working as asynchronous. The two only communicate twice (one way each time), send input, ...wait... get output. Second when Windows Explorer encounters a locked file it does not know what locked the file and never will know. So how is it suppose to tell the Thumbnailer to unlock when it doesn't know it locked the files?

The Thumbnailer is unaware of anything going on outside of its little world, the OS does not notify Thumbnailer some other process is trying to access its locked file. So again how is it suppose to gracefully exit? The only way to solve this is by killing the process and forcing the lock open.

Your solution does not work.

The problem with "thumbs.db" that plagued Windows XP was solved in Windows Vista by using a central thumbnail database. Now why you are getting "thumbs.db" is unexplained? Either the files came from a Windows 2000/ME/XP/2003 machine or as I heard Vista creates them on network drives.

The other problem when dealing with locked files was solved the safe way, as shown in the dialog above.

poet wrote on January 29, 2009, 2:54pm

Why oh why are you insisting that all these system processes can not talk to another?
Even if you assume everything else works just by magic, why shouldn't that magic work here?

And yes, I keep on insisting that the file explorer and thumbnail creator are "system" processes, just because they are vital, fundamental parts of the system. Even if their GUI is not, the functions they use to do their work are. Maybe I need to talk about the "delete file" function, but I actually thought you could think that far on your own.

logic_earth wrote on January 29, 2009, 3:06pm

"Why oh why are you insisting that all these system processes can not talk to another?
Even if you assume everything else works just by magic, why shouldn't that magic work here?"

Its called asynchronous, not synchronous; occurring at different times; (of a request or a message) allowing the client to continue during a processing. Have the two talk to each other makes it pointless to use asynchronous, in turn failing to let the client continue.

Thumbs.db is locked by "explorer.exe" which Explorer process has the file locked? There is no distinction, there is no way to tell what has the file locked. Every explorer windows is the same "explorer.exe" with the same PID.

So again you run into the same problem.

But really lets get to the real issue, why do you have thumbs.db files in the first place?

"Now why you are getting "thumbs.db" is unexplained? Either the files came from a Windows 2000/ME/XP/2003 machine or as I heard Vista creates them on network drives."

poet wrote on January 29, 2009, 4:13pm

Nop, there are many ways for asyncronous processes to communicate. And they are not new, they are quite old, tested and proven, and much of the OS does work that way.

Please stop writing so much pretending to know what you write about, it might actually confuse some people.

logic_earth wrote on January 29, 2009, 4:31pm

Why don't you answer just one question, you keep skipping it.

"Now why you are getting "thumbs.db" is unexplained? Either the files came from a Windows 2000/ME/XP/2003 machine or as I heard Vista creates them on network drives."

As I already said this problem as been fixed in Windows Vista, because it uses a central thumbnail database, it no longer creates thumbs.db. Except as possibly on networked drives.

And you might want to read up on asynchronous.

poet wrote on January 29, 2009, 6:49pm

I don't answer one question, because you don't ask one question.

I don't even know what exactly you want. You started by saying that this problem is "not so easy to solve" and then kept on fabricating stuff why it's not possible to solve. I guess you're just bored and enjoy trying to push the problem away. But guess what, I'm not realy annoyed, I actually like trolls, they are cute, sometimes I even feed them.

You can even syncronize asynchronous processes. It's magic ...

billerr wrote on January 31, 2009, 3:35pm

Something else to point out. Not everyone will do a clean install of Windows. Some people may upgrade from XP. So the thumbs.db will be there for them, and this problem will plague them too. So, either the Thumbs.db files should be removed from personal folders upon installation, or the processes could be made to communicate with each other. The fact that Thumbs.db shouldn't exist in personal folders is of course not the user's fault, so there is no point in asking "why do you have thumbs.db files in the first place?"

However, the problem with locked processes is wider than the Thumbnailer. I haven't digged far into specifics, but is it indeed entirely impossible for asynchronous processes to provide "hooks" or some kind of interaction points provided for occassions when one process would hinder another? I'm not talking for everh third party program out there, just for the processes of the Windows OS, they should definitely be aware of each other, even if they run asynchronously.

AllUltima wrote on January 12, 2010, 7:42am

I know this isn't easy to solve. The fact that it's not is indicative of a fundamental oversight in my opinion. For any type of 'cache' file, the access rights to the file should be so utterly unimportant that anything using them is prepared to have access rights torn from it at any time. Any interrupted write to the file should fail and throw an exception or return an error to the program.

But there is no such level of access currently. So maybe Microsoft should instead change where thumbnails are stored. Or maybe the delete operation can forward a message to the thumbnail generating task and say "let go of this file NOW".