SI
SI
discoversearch

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.
Pastimes : Computer Learning -- Ignore unavailable to you. Want to Upgrade?


To: E who wrote (18781)4/16/2001 2:56:13 PM
From: PMS Witch  Read Replies (2) | Respond to of 110582
 
File locking – a general discussion…

When a computer reads a file, in the simplest case, the file is opened, read, and closed. When a file is open for reading only, the OS reads the files’ directory entries looking for a filename match. Directory entries contain the files’ names, some extra stuff, and the disk locations for the data. Once the OS finds a directory entry with a matching file name, it reads the rest of the directory entry for this file. Now, a copy of the file information is stored within the OS. The OS returns the location for this copy of the information, often called a file handle. In order to read the data stored within the file, the program must supply this handle so that the OS knows which file to use. In short, programs access data through handles supplied by the OS when the file was opened. When finished, programs close files by asking the OS to do the grunt work. Again, the handle must be supplied so the OS knows which file to close.

Let’s look at what happens when two programs try to read the same file at the same time. The first program makes a copy of what it needs from the directory entry for the file and proceeds. The second program does the same. Each program will use its own directory information to access the file data on the disk as needed. It’s like several drivers reading several copies of the same map. When finished, each program will discard the its own copy of the no longer needed directory information.

Consider how different the case will be if data is to be written to the file. Opening the file will be essentially the same process of copying existing directory information and supplying a file handle. The program writes data instead of reads it. As data is written, the OS updates its copy of the directory information. But here’s the big difference: When the file is closed, the OS must update the directory information stored on the disk from the updated copy stored in memory.

Creating a new file is similar to writing to an existing file. The difference being that the OS creates an empty directory entry with a new file and uses the existing directory entry for updating files. Also, opening for Read and Write is identical to opening for Write in most respects.

The chief obstacle with writing files in an environment allowing multiple program execution is ensuring that two programs do not try to write to the same file at the same time. The first program reads the file, and begins making changes to the data. Meanwhile, the next program does the same. The changes the first program makes are recorded to the disk and the updated directory information gets stored. The changes the second program makes gets amalgamated with the first, followed by the directory being overwritten too. One can easily imagine the tangled mess resulting from this. The integrity of the entire disk can be destroyed as the OS writes data guided by a corrupted data map. This would be like allowing several drivers to change the road after everyone else’s maps were printed.

Answering this challenge, OS designers implement systems where files can open for writing by only one program at a time. When the OS opens a file for writing, a lock is established, preventing other programs from opening the file in anything other than read-only. When a locked file closes, the lock disappears and the file becomes available for the full spectrum of operations by other programs. Wise developers take precautions to hold file locking to a minimum. As we can appreciate, locked files have tremendous potential for degrading system performance as programs wait for needed files to become unlocked and available.

For simplicity, I’ve omitted details on how file data is read, written, buffered, or re-written. I’m sure many will sigh in relief. After all, it’s Monday.

Digression…

Programs like ScanDisk and DiskDoctor check that all data on a disk can be located by a directory entry, and that all directory entries point to data. They fix things by gathering orphan data into files, or marking files as possibly corrupt. When Windows shuts down inappropriately, files opened for writing may not have had their disk directory data updated, leaving their data and directory inconsistent. To prevent further damage to the file system, Windows will run ScanDisk before booting. Trouble is, many users aren’t comfortable with the further steps needed for full recovery. They’re still in shock from seeing all those red messages flashing across the screen.

Disk caching makes things worse. (Another story!)
.
.
.

Now to answer your post…

I suggested using a utility to determine which files are locked, and which programs hold the locks. My memory tells me I once used a utility called FileInfo, but I don’t trust my memory. FileInfo indicated which files were open, which program opened them, and the open mode used. What I had in mind was that knowing which program was inappropriately locking files was the first step in eliminating the problem. You would only need to ensure that that program wasn’t running when you defrag.

I also hoped that others would step forward and provide additional information about FileInfo. What I need is a gentle, or not so gentle, reminder about it, such as its real name and where it’s found or downloaded. I hinted that it may be found in the Tools/ResKit area on a Win98 CD, but I don’t have my CD installed, so I can’t look for you. Again, I must repeat, I use FileInfo as a nickname for this utility because I cannot remember the real name.

Perhaps an example would make things clearer. I’ll fabricate one…

FileInfo tells me that a file named MakaMess.Dat is locked.
Windows Information under Software Environment tells me MakaMess.Dat is used by TouchPadHelper.
Close Program (Ctrl-Alt-Del) tells me TouchPadHelper is running.
I halt execution of TouchPadHelper
TouchPadHelper releases lock on MakaMess.Dat
Now, no files are inappropriately locked
I defrag without difficulty.

You’ve assisted the learning process by asking specific questions. This helps us assess your level of understanding and enables us to tailor our answers for you, but sometimes we miss. Feel free to make supplemental inquiries.

Cheers, PW.