[<<]Message[>>] [<<]Author[>>] [<<]Subject[>>] [<<]Thread
Number : 26 Date : 2001-05-16 Author : Kan Yabumoto Subject : Re: Error 5 / Windows Me Size(KB) : 7
At 2001-05-15 19:04, : tguilyar wrote: >When running the following command line after booting from my c: drive: > > xxcopy c:\ d:\ /clone > >xxcopy will not copy the files in the c:\_restore directory to d:. > >The message I get is: > > Copy failed > ## Error 5 ## Access is denied > >This is a Windows Me system. Any ideas what's going on and how I work >around it? > >Thanks!!! ======================================================================== The quick answer is that the error condition reflects the file-sharing violation (which sounds alarming but it is a routine thing). In the case of Windows 95 and 98, the only file that I'm aware of which always results in share-violation is the swap file (WIN386.SWP). ----------------------------------------------------------------- The swap file provides the memory space for the virtual memory implementation (to logically substitute the physical memory by virtual memory in the form of a file on the disk). ----------------------------------------------------------------- Since the swap file is *ALWAYS* open (constantly accessed by Win9x kernel), it is not possible for any application (including XXCOPY) to access the file. In Windows ME (and NT/2000) there are many more files that are similarly open all the time and therefore fail to be accessed by XXCOPY. This is normal --- of course, the backup job is not perfectly done. In the case of Win9x/ME, when you examine the failed files, they are usually non-essential files (such as system activity log, etc.) whose absence in the backup file set would not cause serious problems. If you are a purist and you want to copy them, then, you must access them from DOS (not a DOS-BOX) which Microsoft make is very difficult if not impossible under Win ME (that is one reason why I still stay with Win 98SE like many other people. -------------------------------------------------------------------- Here's a little longer answer: Microsoft's popular Windows operating systems (except DOS) are all multi-tasking operating systems where many processes are running at the same time. Whenever you have two or more programs running and they inevitably access files, sooner or later, simultaneous accesses to the same file will take place. Here's a classic example if simultaneous file access (somewhat simplified scenario): Say, you are downloading a very large MP3 file from Napster (are they still in business?). Say, you are copying a file "Beatles A Hard Days's Night.MP3" into a directory in C:. This file is now opened by the Napster program and the file gradually increases in size while being downloaded. Since it takes so long, you decide to run a system backup: xxcopy c:\ d:\ /clone When XXCOPY hits the Napster directory where the new MP3 file is being written, the file would be accessed by the two programs simultaneously. There are several scenarios for situations like this. It all depends on how the file-sharing is handled by the applications (in this case by Napster and XXCOPY). When Napster creates the file, it has the first shot at how it wants the file-sharing resolution be handled by the system. It may say "No other application shall access this file until it is done and closed". It is the discretion of the Napster program. My guess is Napster programmer chose the most common method --- not to allow other to access while the file is being downloaded. If the first application is "anti-social", no other application can access it. But, if the file access is for read-only (the application has no intention of changing the contents), then, it is generally safe for other application to access the file simultaneously --- as long as the late-comer does not alter the file. This is the most common safe file-sharing case where two or even more applications access the same file for read-only purposes. As you can imagine, if one of the applications has intention to modify the file, the situation will become more complicated. From XXCOPY's point of view, when other application(s) prohibit XXCOPY's read-access, then the file cannot be copied to the destination. The second case which involves a file-write operation complicates the matter. When the first application is happy accessing a file in read-only and is willing to share with others; but you run XXCOPY and try to overwrite the file with a newer version (in this case, the shared file happens to be in XXCOPY's destination). Of course, it would be so disruptive to allow the late-comer to change the file contents while the first application is reading the file, this is usually not permitted (the first application can specify that it is willing to let others share the read-only access as long as they do not disturb the contents). These rules make sense --- just, the rules are quite messy and a headache for programmers (that's why many programmers choose to play safe by being anti-social --- trying to be nice to other programs comes with a big burden to do it right). Another common case is file-locking. When a huge file is opened by a database application, typically only a small portion of the large file is updated at one time. In that case, the database application will be extra nice to other application by allowing the access to the portion of file which would not be affected by the small change. The database application perform this by locking the specific region of the file (prohibit other applications to access the region) for the duration of the update. As soon as the update operation is complete, the region is unlocked and other application can once again access the file. The Windows 9x system registry files (SYSTEM.DAT and USER.DAT) are handled in this fashion. Although these files are open at all time, they are still accessed by XXCOPY for read-only purposes (XXCOPY would fail if you try to overwrite these file). In most cases, when a file-access is denied by a temporary locking mechanism, the late-comer would just sit tight for a fraction of a second and try again, and the lock will eventually be gone and can continue its file access. When XXCOPY encounters a file access failure, it is usually not possible for XXCOPY to determine whether it is a temporary situation or a permanent problem. Therefore, XXCOPY will give a few tries with some interval. It will eventually give up after a few seconds and go on to the next file. You may increase the trial period by the /CR switch ---e.g., /CR60 will set the retry period of 60 seconds (the default is 3 seconds). ---- Well, I've been carried away with the gory details of file sharing and locking. What I wanted to say here is that the programmers who write the application programs try their best anticipating simultaneous accesses and do the most reasonable thing. Usually, a quick-and-dirty programs tend to be more restrictive in sharing (because it's easier) and a better written program with care will go extra miles to accommodate even rare situations for an optimum result. Anyway, XXCOPY is written as a "well-behaving" program --- it abides by the common rules for programming --- uses only the set of file I/O APIs which are documented by Microsoft's official documentation in the Win32 environment. I promise, next time, it wont be this long... Kan yabumoto
This message if part of XXCOPY's message Archive. The archive contains all the messages posted at Yahoo!Groups: XXCOPY.