# Moving web pages saved by IE (HTM file & \_FILES folder) **URL:** https://resource.dopus.com/t/moving-web-pages-saved-by-ie-htm-file--files-folder/7826 **Category:** Help & Support **Created:** [May 4, 2009, 2:22pm UTC](https://resource.dopus.com/t/moving-web-pages-saved-by-ie-htm-file--files-folder/7826 "2009-05-04T14:22:07Z") **Posts on this page:** 1 **Showing post:** 5
### Author: ![Leo](https://resource.dopus.com/user_avatar/resource.dopus.com/leo/32/69732_2.png) [@Leo](https://resource.dopus.com/u/Leo) #### Post date: [May 5, 2009, 10:48pm UTC](https://resource.dopus.com/t/moving-web-pages-saved-by-ie-htm-file--files-folder/7826/5 "2009-05-05T22:48:59Z")
If you want to raise unrelated issues please start a new thread, as per [the FAQ which nobody seems to read](https://resource.dopus.com/t/ask-one-question-per-thread/5444/1). A laundry list of issues will become a mess of interwoven threads which nobody can keep track of. Still, I'll bite... (Note: I'm not part of GPSoftware and I'm not talking on their behalf here.) I don't understand why you think that Opus is alone in not following Explorer's Connected Files system. Virtually other file manager supports it, aside from the very basic file managers which call on Explorer to do everything. Most people consider it a defect not a feature. > [@](#): > > For starters, its use of non-conventional Windows colors. What non-conventional colours? The green/red source/destination? Windows doesn't have standard colours to indicate those things so what should Opus use instead? (You're free to change the colours to whatever you want via Preferences.) I suppose Explorer also uses non-standard colours because it has Green or Blue (depending on OS version) back buttons whose colours do not come from the Display control panel's Appearance page? > [@](#): > > Eventually, it dawned on me that if you repeat hitting CTRL-X it simply toggles on and off. I've send a report to GPSoftware to get that changed as it does seem wrong. Mentioning it in the middle of a 1700-word rant is a pretty bad way to get problem reports noticed, though. > [@](#): > > 2.1 Clearly, D.O’s developers are unaware of this problem Not only its developers but its users, until now, as you are the first person to ever mention it AFAIK. 🙂 Once someone mentions things and files a report it'll probably get fixed. Until then there are bound to be things that fall through the cracks. The developers can't notice everything by themselves. (And it's not like Explorer isn't riddled with bugs as well, not that it's any excuse, but bugs and quirks happen in all software. Report them and they should get fixed if everyone agrees the behaviour is wrong.) > [@](#): > > 2.2 That this ‘toggle’ only goes through half an on-off cycle makes things worse... I doubt it's intentional behaviour so there's no need to deeply analyse the fact that pushing Ctrl-X when nothing is selected clears the clipboard. (On a technical level, I guess Opus is doing something valid: It's putting the selection -- nothing -- into the clipboard. But obviously nobody really wants that to happen if they accidentally hit Ctrl-X. I doubt it's on purpose; it's just that nobody has noticed or reported it before.) > [@](#): > > 2.3 In the installation it is recommended that D.O. be installed to replace Explorer by default (this would overcome my last point in 1.2), however there is considerable arrogance in adopting this approach, here's a few reasons: Arrogance in assuming someone might wan to use the program they're installing, while giving them the option of turning that thing off? Eh? I suppose it's arrogance that when you install a media player it offers to take over the filetypes it can handle? Opus handles folders so it offers to take them over. > [@](#): > > (i) It presupposes that every user of the PC is familiar with D.O. Failure to warn other users that D.O. is installed could result in them losing data. How does installing Opus result in anyone losing data? If you're still talking about the IE web page thing, it's hardly destroyed; you just have to move the other half of it to the same place and everything works fine. Calling that "destroyed" is rather melodramatic, don't you think? > [@](#): > > (ii) In some operations D.O is considerably slower than Explorer, thus a once-confined effect is now commonplace across all file operations. Which operations? If you're taking about copying files be sure to do a fair test. Tell Opus not to copy attributes and dates (as Explorer does not and doing so slows things down) and be sure to copy data that is not cached as a result of copying in the previous program. Lots of people have made the claim that Opus copies slower than Explorer but in every single case that I know of, where we're talking about typical local HDD-to-HDD copies, once their testing methods were made fair, the speeds turn out to be about the same, as you'd expect. (There are some pathological cases where Opus is currently slower but you're unlikely to run into them. Equally there are cases where Opus is faster. No one file-copying method is fastest for every situation.) > [@](#): > > Even with my very limited experience of Directory Opus, I've found that it isn't as crash proof as Explorer, I've had it crash repeatedly under certain conditions when in identical circumstances, Explorer repeatedly does not. Then use the FAQs on tracking down the cause of crashes and report what you find here or to GPSoftware directly. Crashes are almost always caused by interactions with 3rd party components and so people need to bring them to the attention of those who can investigate and add a workaround. In the long run Opus could move some of that stuff into a separate process so that if 3rd party components crash they don't take out the main process. That has a performance hit and isn't a simple change but it might be wroth it. That's exactly what Explorer has moved to, more and more as it faces the same problems that Opus does (except life is easier for Explorer because everyone tests against it). > [@](#): > > (v) For example, D.O. will crash repeatedly whenever it encounters say an image file (JPG etc.) that's damaged in a certain way I assume you've reported this to GPSoftware and given them an example JPEG. If not how can they fix what they don't now about and have no way to reproduce? I doubt there's an image viewer in the world which hasn't had crash-bugs with malformed inputs. That's life. Report them and they are very easy to fix. > [@](#): > > Seems D.O. caches the file and the viewer DLL goes belly-up, however Explorer does not crash in the same circumstances. (BTW, this is the same problem as the PowerDesk had years ago). FWIW Opus shouldn't be using a viewer DLL for JPEG files so if you've seen a crash within a DLL's address range please mention which DLL it was in the report as that could help track it down. You mention PowerDesk so it's possible that the crash is happening in the Stellant viewer DLLs which Opus will hook into if they are there (which used to come with PowerDesk as well, but don't actually come with Opus even though it'll use them if they're there), though it'd be strange for them to be involved with a JPEG. > [@](#): > > (vi) It is simply not acceptable for an Explorer-replacement to crash when it encounters a wayward file Explorer can crash in exactly the same way, especially if we're talking movie files and you have a badly written movie codec installed. If you want to reduce the risk of Opus crashing, disable everything that can interact with 3rd party code. IN particular, disable the ActiveX plugin, the Movie plugin, the MultiView plugin and the Thumbnails: Shell Image Extraction option. You'll find Opus doesn't do as many useful things with media files as a result, though.... Much better to work out which component on your system is crashing when Opus asks it to inspect a particular file and either see if there is a fixed (or alternative) version of that component, or report the crash and send a sample file either to the forum or to GPSoftware in case a workaround can be added. > [@](#): > > However, the subject of my initial post about saved Internet page files not automatically following the page is clearly an omission from Explorer's basic feature set. I honestly feel that the vast majority of people would disagree there, but if you really want that changed then write to GPSoftware via their support page. I suspect you'll be the first to ask, though, as most people I've seen mention that aspect of Explorer hate it. > [@](#): > > 4. In Windows, where words like verification, authentication, encapsulation and data integrity checking are essentially foreign notions without meaning, one expects to be diligent with one's data. Nevertheless, there's no excuse for D.O. not having extra verification checking on dangerous options, which if selected in error, would be disastrous. What is so dangerous here that it requires a warning? It's not like Opus deleted the other half of the saved web page after moving the half you moved acted on. The other half was still there and could be moved as well. Isn't it more dangerous to do what Explorer does and act on files/folders which the user has not actually selected, just because they have similar names which may be a coincidence? > [@](#): > > 4.1 For example, in File Operations/Copying Files/[tick] Preserve the timestamps of copied files, it would be easy to accidentally deselect this option and be none the wiser until it's too late. At the very minimum, attempting to 'untick' this box ought to automatically invoke an instant 'Are you sure?' response. You want to be asked to confirm individual checkbox changes in Preferences, via pop-up dialogs that appear the moment you touch the checkboxes? That would be so annoying. Sorry but if someone goes clicking random checkboxes in Preferences without thinking about what they mean then I think a few file-copies timestamps being bumped is the least of their worries. Meanwhile everyone else would be really irritated by being asked if they were sure they wanted to turn on the thing they just turned on. > [@](#): > > Even then, subsidiary options are needed such as a fall back to the 'on' position after a single copy or a session of copies--leaving this box 'unticked' ought to be very difficult (although I certainly would not like to see the feature removed). You can create buttons, menu items or hotkeys which run versions of the Opus's Copy command that override the settings in Preferences. That's generally a better way to do it than changing the settings before and after doing the copy. > [@](#): > > 4.2 There is no reasonable excuse for this option being the way it is, it is either sloppy programming or a failure to grasp the full implications that unticking this box might have, or both. I don't get this at all. If the user doesn't want timestamps to be copied then they can turn them off. How is that unreasonable? > [@](#): > > Nevertheless, the lack of compatibility with Explorer's defaults has almost certainly excluded it from widespread deployment in my workplace. It's funny that you praise Opus for deviating from Explorer's defaults where it coincides with what you personally want, but condemn Opus for doing the same when it isn't. With that attitude Opus can't win. Opus isn't Explorer, it's an alternative to Explorer which does the things that its makers think make the most sense. You'll never get two people to agree 100% which things make sense to change and keep the same. Luckily Opus has a huge amount of options which keep its users happy, in general, but if an option is missing then by all means write to GPSoftware and request it. --- _[View the full topic](https://resource.dopus.com/t/moving-web-pages-saved-by-ie-htm-file--files-folder/7826)._