Disgracefully unreliable software
Software can be made pretty reliable, lots of people and companies know how to do so. The auto-pilot on an airplane comes to mind, as do the computers that run financial markets. Then there's mainframe computers, perhaps the classic example of reliability (I spent many years working in a mainframe environment). But chances are that the computer you are reading this on is not as reliable as it could be.
Impolite Waiter
Let's start with an analogy. How would you feel if you were in a restaurant, in the middle of your meal, and the waiter takes your food away? It's a breach of the rules; food isn't supposed to be removed while the customer is eating.
Windows XP is that waiter. It lets you delete a file while an application is using it.
I ran into this recently while viewing an image with the popular IrfanView program. I was cleaning up files and deleted some pictures only to realize later that IrfanView was still running, minimized in the taskbar, and viewing one of the just deleted pictures.
This should never be allowed to happen, and it doesn't on a mainframe.
Windows knows full well what picture IrfanView is using. IrfanView didn't scan the sectors on the hard disk by itself to figure out which ones constitute the picture. It asked Windows to grant it access to the file. But when it comes time to delete a file, Windows has amnesia.
IrfanView is only one example. Windows XP will delete pictures while they are being used by a running copy of both Paint and the Windows Picture and Fax Viewer too.
Adding insult to injury is that Windows makes the opposite mistake too. Many times when I'm finished using the files on a USB flash drive, the Windows "Safely remove hardware" function won't let go because it thinks one or more of the files are still in use.
Multiple Updaters
Open a file in WordPad. Then open the same file in Open Office. Now both programs updating the same file at the same time. How come no one at Microsoft ever saw this as a problem?
To be clear, the gripe here is about Windows XP, not WordPad or Open Office. The operating system is in charge of the files. It has the responsibility for integrity, so it should not allow two programs, any two programs, to update the same file at the same time. Anyone with a database background knows what comes next.
Open a plain text file with Notepad and then open the same file with AbiWord (again the specific applications are not the issue). Make a change to the file with Notepad, save it and close Notepad. Open Notepad again and you will see the change that it just made. Now make a change with AbiWord and save the file. The change that Notepad made is gone. Disgraceful.
Ubuntu Linux
There's no gloating in Linux land either.
In a virtual machine running Ubuntu 7.04, I double-clicked on an image and opened it in the default application, Eye of Gnome. Here too, I was able to delete the image while viewing it. I also tried opening an rtf file in Open Office v2.2. Again, I could delete the file while an application was using it.
Ubuntu fared no better with multiple editors. I was able to open a file in both gedit and Open Office v2.2 at the same time. Changes made in gedit and saved, were wiped out by later changes made in Open Office. Just like Windows XP.
Java
This brings to mind my initial experience with the Java programming language back in February of 2001. The first thing I did was to write a simple program that added two numbers and printed the result.
To explain why I chose this as my first Java program, let's suppose that all numbers are limited to a single decimal digit. Then, if you add 1 and 1 you get 2. But, if you add 4 and 8, you should get an error since the result is larger than a single digit.
Along these lines, Java has a numeric data type called "integer" which is used for integer numbers up to 2,147,483,647 (let's call it 2.1 billion for the sake of argument). In my first Java program, I added two integer numbers and stored the result in a third integer - the code is below:
int var1, var2, var3;
var1 = 2111000333;
var2 = 1000222333;
var3 = var1 + var2;
System.out.println("var3=" + var3);
This adds 2,111,000,333 and 1,000,222,333. The result--roughly 3.1 billion--is too large to fit in an "integer" variable. I wanted to see how Java handled this. The result was:
var3=-1183744630
Not only is the answer wrong, but Java didn't crash, as I expected it would. Mainframe programs crash when they encounter this type of error - better to fail than produce wrong results.
Java didn't even issue an error message.
Update: October 22, 2007. I was asked by CNET if the above Java issue still exists. It does. Using Sun's JDK version 1.6.0_03 on Windows XP, I was able to re-create the problem. A screen shot is below.
Michael Horowitz is an independent computer consultant and the author of several classes on Defensive Computing. He is a member of the CNET Blog Network, and is not an employee of CNET. Disclosure. 
Only when the open file is closed will its space be reclaimed by the UNIX operating system for use by other processes.
This can be seen by comparing du output with df output. du will not show files that are "unlinked" in this way; df will correctly report free space (taking into account files open but unlinked).
Linux follows this pattern in the same way that UNIX does. It is entirely possible (and likely) that Windows follows this same rule with regard to the deleting of open files.
If a file is open in an app, the disk copy gets deleted, and you still want to save it, simply "save" or "save as" the critter and it is perfectly safe. This is because a copy of the file is still loaded in RAM and/or virtual memory/swap.
As for multiple apps writing to the same file, this behavior is the apps' fault in *nix... you can always create a lock file that references the file being opened (e.g. in /var/lock/$foo), which --through the kernel itself-- will prevent any other process from opening the locked file. If you can double-edit a file without any sort of warning, then the app is generally to blame in UNIX/Linux/BSD. To top that off, if you don't want to get all drastic, the app can always grep the relevant bits of /proc to see who else may be handling the file. There are literally dozens of mechanisms that you can use in *nix to check for file state.
In both *nix and 'doze, I'm very sure that the kernel/OS provides a listing of what files are being used (you know, like in /proc)... if the app coder isn't smart enough to check for this, then it's his fault, not the OS'
/P
But, more sofisticated frameworks, such as COM, keep so called Running Object Table. If you open a file by different COM-compliant applications, multiple open will be detected, even though the actual file handle is mot kept open. You won't be allowed to open the file twice for editing.
it is really important to realize why Java did what it did when adding those
two numbers: it's called integer overflow, and it's quite normal, because the
amount of bits that you have are limited depending on the type of variable
you're using.
http://en.wikipedia.org/wiki/Integer_overflow
Say, a number that only has four bits to represent itself will only go until
1111 (binary form of 15), if you add 1 to that it will go to 0000 with a 1 in the
overflow register. That is how it works, down to the assembly code. It's not a
misjudgement of the operating system, it is how the programmer codes.
Which leads me to my next point:
The instability/security of a program doesn't really only rely on the operating
system itself. I'm not defending Windows here: I agree with you, in part,
because it can be better. However, I feel that it is also important to mention
other variables that are relevant, like the programmer. Integer overlow, for
instance, is something that a programmer should always consider, security-
wise, and must program accordingly to prevent it or announce it if need be,
which I think is the best alternative if it did happen. In your case, issuing a
warning would be sufficient for the user to know what has happenned and to
rectify by using another type of variable.
By the way, Java didn't give a wrong answer: the negative sign is a good hint
that it overflowed, and that answer actually is the correct one, it's just not the
one you expected with your decimal system mind in place, where all numbers
have infinite amount of bits to be represented with.
Finally, in my opinion, letting the program crash should never be an
option. If we should expect the system to crash when something like this
happens, a situation like the one in the next link can arise:
http://www.gcn.com/print/17_17/33727-1.html
and I don't think it's the best alternative.
As a non-techie layperson, I don't see the problem in what you seem to pose. If two applications are simultaneously using one file A, and application 1 performs operations on A and is then closed down, why wouldn't you expect the subsequent operations performed by application 2 to be subject to/recognize the previous operations performed by application 1?
I must be missing something. Garcon, sil vous plait.
This sounded kind of fishy to me because I know I've routinely tried to conduct this stupid behavior at work with similar results.
I guess you should try again.
- by ligart June 26, 2008 7:41 PM PDT
- Don't know what mainframe you were using, but on the IBM System 370 - 390 (VM / CMS) you can be editing a file in XEDIT, shell out to FILELIST or the CMS prompt (i.e. file is still in memory in XEDIT), erase the file you are editing w/ no error message, then return to XEDIT. You don't even need to shell out - you can issue the erase command from within XEDIT while editing the file! CMS has always had this capability. And I've "been in the mainframe environment for many years", too ... like 25 of them.
- Like this Reply to this comment
-
(9 Comments)