I've been looking at Opus for about a week now and after the initial overwhelm of features I have it configured pretty much the way I like it.
I am having a problem though. After downloading a large file to say C:\downloads I then cut and paste the file and put it somewhere else. When I go back to C:\downloads it still appears to be there. When clicked it will highlight but the right click menu will not appear. After a reboot it does not show up. What's all this about?
Does pressing F5 make it disapear?
Do you see the same problem in Explorer?
I can think of reasons why this might happen with network drives (there's an option which disables change notification on network drives) but it's strange if it's not working on local drives, and even more so if you're moving the file using Opus itself.
That said, if the file is still there after an F5 and/or you also see the problem in Explorer, then it sounds like a problem outside of Opus as the filesystem is still reporting the file... (If it only seems to happen with large Zip files I'd bet it was a virus checker holding the file open while it checks everything in the archive.)
Sorry not to have the answer if you were curious but I just rebooted a minute ago and the problem is not occurring any more. Very odd. Thanks for taking the time anyway.
I have recently noticed similar behavior on a fixed FAT32 volume (I should note it's on a hardware-controlled, striped RAID 0 array). However, I'm not seeing this with files but with folders. It happen sporadically when:[ul][li] Moving a folder full of subfolders and files[/li]
[li] Performing a one-way synchronize that deletes obsolete objects (including some folders) from the Destination lister[/li]
[li] Using a Delete SHIFT command button to delete a folder and its contents[/li][/ul]After such an operation I'm left with an empty folder that I cannot delete. (It still appears after F5 refresh.) After a period of time, the folder usually goes away on its own, but sometimes a reboot is required. When the folder remains, clicking on it results in Windows prompting for which application to open the folder with (like it was an unrecognized file type). I have not noticed a size requirement here in terms of the number of files/subfolders or bytes within the afflicted folder.
I'm still collecting analysis to send to Greg and Jon. But here's some things to look out for:[ol][li]Do you have Write Caching enabled on the drive in question?
If so, there could be a delay between the move occuring and the move being completed, and reported to the OS.[/li]
[li]Is the volume you moved from on a RAID array?
If so this adds another reporting layer to the process and creates a delay.[/li][/ol]The fact that your file is gone after a reboot, does not mean the root problem did not exist. Keep looking out for it and document what you did, and what you see.
I have not been able to duplicate my results in Windows Explorer...yet. But then again I rarely use WE.
The problem has returned but I have part of the cause. The drive is NTFS and not part of a RAID array. What is happening is that the files that were cut and pasted are locked by another program but Opus was still able to copy them without giving a locked error message. The files that were copied to another folder are then readable from the destination folder but no longer from the source in Opus. Looking at the source in Explorer the files are still there too but using the wholockme (tinyurl.com/e3tz4) utility I can see the files as being locked and by what application. The same utility works in Opus but not after the move. When right clicking on the moved file no menu appears.
So it is okay that Opus can move the files to a different folder but I think it should be able to show the right click menu after this has been done.
Delete + shift gives a locked file type message. F5 makes no difference.
I just found out the culprit to the specific issue that I posted in above in this thread. It hasn't happened to me in a few weeks, until just a few moments ago. This time, I was ready for and waiting for it--I had Unlocker installed which caught the scoundrel responsible red-handed.
The specific executable that was locking the folder in question was cisvc.exe, a component of the Windows Indexing Service.
[quote="Windows Services Management Console"]Indexing Service
Indexes contents and properties of files on local and remote computers; provides rapid access to files through flexible querying language."[/quote]
[quote="The MSDN Authors"]
Change-Notification Component
The Change-Notification component informs Indexing Service when files have been altered (added, modified, deleted) to trigger indexing or re-indexing of the contents and values of changed files.
The Change-Notification component is part of the cisvc.exe file.
Indexing Component
The Indexing component calls the Filtering component to extract the text and values from files that need to be filtered. After additional processing, it merges the resulting word lists into an index that is saved to disk. Indexing Service eventually merges content information (the text within a file) into the master index and saves value information (properties internal to the file) in the property cache.
The cisvc.exe file contains the Indexing component.
Scanning Component
The Scanning component detects file modifications that trigger filtering of the files. If all indexed files exist on drives that support change notification in some way, scanning operations are only necessary the first time a catalog is created or during crash recovery. Otherwise, the Indexing component calls the Scanning component when the operating system has no way to flag change notifications.
The cisvc.exe file contains the Scanning component.[/quote]
When I used Task Manager to kill the cisvc.exe process, the folder immediately disappeared.
I had enabled the Windows Indexing Service a few months ago to look at it. In the modern day craze of desktop search engines, most people do not realize that the Windows operating system comes with an indexer and search engine built-in. It's not as sexy as Yahoo! or Google's. (and apparently is the cause of several system slow down and other issues such as seen in the articles below.[ul][li]Indexing Service(System Services for the Windows Server 2003 Family and Windows XP Operating Systems)[/li]
[li] KB329065 - PRB: Access Denied Error When You Make Code Modifications with Index Services Running[/li]
[li] KB899869 - Windows XP may run slowly and you may see multiple symptoms in Windows Task Manager[/li][/ul]I'm theorizing (or speculating) it is a hit-or-miss thing when the user deletes a folder in Opus (usually a large sized folder full of files) that cisvc.exe may have indexed (or might even be indexing at that time) is probably the cause.
The trigger event I saw went as follows:[ol][li] I started a rather large copy operation in Opus.[/li]
[li] I realized I made a mistake and canceled the operation.[/li]
[li] I attempted to delete the files and folders that had been copied.
RESULTS: All files were successfully deleted, even those below the subfolder that was locked. All subfolders except the one were successfully deleted.[/li][/ol]To my best recollection, the other instances where I experienced this issue were similar to the one described above. I was always copying and deleting files, rearranging folder contents and performing Synchronizations (which does the same steps as I describe above).
RESOLUTION:
To turn off the Indexing service, follow these steps:[ol]
[li] Open Windows Explorer[/li]
[li] Click the Search button on the toolbar.[/li]
[li] Click Change preferences[/li]
[li] Click on the Green Arrow icon next to Without Indexing Service.
NOTE: This listing will be named "With Indexing Service" if Windows Search is not currently configured to use this service.[/li]
[li] Click No, do not enable Indexing Service.[/li]
[li] Click on Change Index Service Settings (Advanced)
A Management Console window appears. If Windows was ever configured to build an Indexing Service catalog, the path to this catalog will be listed in this window. If you see such a path, right-click on the entry and select Delete. Then close the Management Console.[/li]
[li] Once back in Windows Explorer, click OK, close the Search Pane, and then close Windows Explorer.[/li]
[li] Open the Services Management Console: click on Start Menu > Run, type "services.msc", and press Enter.[/li]
[li] Locate Indexing Service from the list of services, and double-click on it to open the Properties form.[/li]
[li] On the General tab of the Indexing Service Properties dialog, in the Startup type drop-down item list, click Disabled.[/li]
[li] Click OK.[/li]
[li] Close the Services Management Console.[/li][/ol]
I've seen this as well. When a file can't be opened Explorer will show the right-click menu while Opus won't.
It doesn't happen often and the only time it's mattered to me was when file permissions were preventing the file from being read (since I wanted to get to the Properties dialog, via the context menu, to change the permissions).