Samba uses TDB (Trivial DataBase) and it does something like this. It allows multiple readers and writers to work on the same file (database) without having a lock manager process that would be a single point of failure.
Well, it turns out that windows can use unix semantics (with the FILE_SHARE_DELETE flag), but I still don't know if it can be used for system files.
I'm sure windows could be fixed so that parts could be restarted, but it would be a major project that would take years. But they probably won't do it since every windows system in a large deployment is part of a cluster of servers, so one going down for a reboot isn't much of a hassle. It's where you don't have a cluster that it is a problem.
In the CreateFile() call that opens the file, use FILE_SHARE_READ | FILE_SHARE_DELETE in the dwShareMode parameter.
The MSDN documentation doesn't make it clear at all, but FILE_SHARE_DELETE works with MoveFile() in the same way it does with DeleteFile(). In other words, it gives you Unix-style delete/rename semantics. Even while you have the file open, Windows can delete it or rename it right out from under you, but you can keep reading it--your handle to the file remains valid until you close it.
So, in the case above, Windows moves the file to the destination folder without interference from your thumbnail code.
Mike Mascari ran a test of this and posted the results in the comp.databases.postgresql.hackers newsgroup:
Well, here's the test:
foo.txt contains "This is FOO!"
bar.txt contains "This is BAR!"
Process 1 opens foo.txt
Process 2 opens foo.txt
Process 1 sleeps 7.5 seconds
Process 2 sleeps 15 seconds
Process 1 uses MoveFile() to rename "foo.txt" to "foo2.txt"
Process 1 uses MoveFile() to rename "bar.txt" to "foo.txt"
Process 1 uses DeleteFile() to remove "foo2.txt"
Process 2 awakens and displays "This is FOO!"
On the filesystem, we then have:
foo.txt containing "This is BAR!"
The good news is that this works fine under NT 4 using just MoveFile(). The bad news is that it requires the files be opened using CreateFile() with the FILE_SHARE_DELETE flag set. The C library which ships with Visual C++ 6 ultimately calls CreateFile() via fopen() but with no opportunity through the standard C library routines to use the FILE_SHARE_DELETE flag. And the FILE_SHARE_DELETE flag cannot be used under Windows 95/98 (Bad Parameter). Which means, on those platforms, there still doesn't appear to be a solution. Under NT/XP/2K, AllocateFile() will have to modified to call CreateFile() instead of fopen(). I'm not sure about ME, but I suspect it behaves similarly to 95/98.
I would immagine that it was inherited from somewhere else, either VMS or the other family tree of windows for compatability. Hopefully someone who does know will point it out...
One of the nice things about the windows semantics of "can't have two writers" is that programs can test for writability to see if someone else has the file open for write. This is used by word to keep two people writing to a file while another has it open. It also cuts into flexability as my origional post shows.
In the unix world, all locking is at the application level and nothing prevents someone else modifying a file you have open (as long as they have write permission of course). So there is greater flexability and greater ability to shoot your whole foot off, instead of just shoot yourself in the foot.
How will the new Mozilla license scheme affect developers who want to use Mozilla code in creating and distributing proprietary applications?
Not at all; developers creating and distributing proprietary software incorporating Mozilla code will be able to continue to use that code under MPL terms and conditions, exactly as they have been doing all along.
The MPL was originally designed to allow source files distributed under MPL terms to be combined with source files under other licenses, and the resulting work to be distributed under a non-MPL license. (This right is contingent on the requirements of the MPL being fulfilled. For example, when distributing the resulting work to users, the distributor must also make available to users the source code for that portion of the code created from the source files distributed under the MPL.)
This feature of the MPL has allowed developers to distribute proprietary products incorporating Mozilla code. (Netscape 7 is one example of such a product.) Under the MPL/GPL/LGPL triple license scheme developers may continue to create and distribute Mozilla-based proprietary products, by taking advantage of the option to use the Mozilla code under the MPL terms and complying with the various requirements of the MPL for those portions of the proprietary products based on Mozilla code.
(In theory developers could also distribute Mozilla-based proprietary products using the Mozilla code under LGPL terms, if the Mozilla code were in the form of a library and the developers complied with the relevant requirements of the LGPL.)
One thing that doesn't mix well with cycling is nice clothes, and making a good impression upon arival.
You are sweaty and so are your clothes unless you bring a change of clothes when you get to work.
Having been in a car accident recently and being carless (didn't have insurance at the time...) I have been walking a little over 1 mile each direction to work. I have lost weight, and I find that while I do sweat, it is much lighter than when I used to cycle where it was mostly from the main sweat producing glands (arm pits, back (mostly from the backpack), and chest).
"Thats all fine and dandy, but doesnt' change the fact winodws still needs to be rebooted:)"
I was showing why windows will never be able to catch up in requiring as few reboots as unix OSes. If you didn't catch that, please read my previous post again, it was kinda long...
"And says windows is useing an outdated not so good filesystem."
Why do you say that?
NTFS supports all of the unix sematics natively. In fact, everything is a file -- even directories and "inodes".
You have a combined inode list and journal in the MFT file.
(in fact, the design of ext2 and 3 keeps the inodes close to the data with block groups spread out over the disk. (these block groups also provide a level of backup information that that helps greatly during filesystem recovery on bad disks -- but you have backups, right?)
So, if you implement NTFS so that the MFT file is intentionally fragmented to put the inode data close to the data blocks, you could have the same performance advantages ext2/3 does for reads on large files (I'm not sure what XFS does to get its speed advantages though). Or whatever else might be a better layout. But you wouldn't have the recovery advantages of ext2/3's block groups though.)
If the FLOSS community could just fork NTFS from the specs published before microsoft changed the FS and didn't publish the specs, NTFS could be one of the premiere filesystems in Linux. But alas, NTFS support in Linux and OSX is not about optimizing for production use, but for compatability with windows systems.
Fragmentation can be overcome by a better implementation like Suse's enhancements to ReiserFS does in the 2.6 kernel. (Did that make it in yet? I haven't been following LKML for the last several months.)
Just like ext2/3 for windows might not be as reliable because it might not follow the same integrity procedures that the linux kernel implementation does -- almost by requirement since since Linux's ext2/3 implementation is gpl, and I don't believe the MS FS SDK is gpl compatible.
"* I know. But OS X is not Unix, never has been, and probably never will be. I'll believe it's Unix whe the Open Group tell me it is."
Neither is Linux.
And the new extensions coming out in Xorg seems to allow the features of quartz in X. Maybe some day quartz will just be an abstraction layer to X + extensions.
Apple has created several proprietary parts where there weren't standard parts, but are surprisingly open for a non-linux company.
I'm not an OSX wizard, but finding out that the software raid on OSX only works with entire drives is an artificial limitation. I don't know what it does for LVM either.
It isn't the integration that causes requirements for reboots.
It's the base concept of not being able to move or rename a file once it is open. This is the same whether you are talking about a simple text file, or your system files for the OS.
Most filesystems (fat, ntfs, and of course all unix filesystems) have an abstraction between a directory entry, and a filesystem wide number that identifies a file -- in unix filesystem terminology that is the "inode". The problem is that windows does not use that natural abstraction.
In unix, if a program has a file open, you can "delete" that file -- wait it's not gone yet[1]. What happens under the covers, is that your filename in a directory points to an inode. Each inode has a count of the number of references to itself. When you open the file that reference count for the inode is incremented. So if there is one program with the file open, and the inode is referenced in one directory, the reference count is now two. Once that count goes to zero, the inode is unlinked -- which means deleted, but since "delete" is multi-step in unix, you need more terms.
[1] This is a great way to work with temporary files -- once you open and delete it, nobody else can access the file and many security threats with temp files are completely avoided.
Now you have a system file that needs updating. You delete the file (which just removes one reference from the directory) and the system still holds a reference to the inode and continues operating as before. Then, you write the new updated file to the same directory with the same name, but it doesn't cause a conflict because the new file goes into a different inode. Once the files are replaced, restart the individual application and the update is finished.
On windows, to update a system file that can not be closed during the operation of the system, you put the files in a special location with a script that specifies their desired location. Every time windows boots it runs those scripts that replaces files before they are opened. That is why windows will always require more reboots than unix based OSes.
There is more to updating system files than that of couse. For instance, most unix servers do not run a graphical environment on the server and every version of windows since NT boots into a graphical graphical environment. Most Unix based systems use the Xwindows system for their graphical environment, and an update to that environment only requires a restart of Xwindows not the entire system -- which is important if you are running any services on your computer that people depend upon.
Yes, this is exactly the meaning behind my origional post.
Charging is for people who are annoyed by their friends/family that constantly ask you to fix their systems, and refuse to do it for themself. If that doesn't bother you, then don't charge them. It's that simple.
Before you start adding a lot of extra error reporting, it should be designed in such a way that it will be extendable in the future so that you don't end up with an unmanagable error reporting system.
Slashdot Mirror
and as long as that product is part of a Novell product (Currently Suse)...
Now that would really cut into the quik.
Why emulate when I was born with two native ones?
Yep, agreeing...
Yell out...
No bitch!
Samba uses TDB (Trivial DataBase) and it does something like this. It allows multiple readers and writers to work on the same file (database) without having a lock manager process that would be a single point of failure.
Well, it turns out that windows can use unix semantics (with the FILE_SHARE_DELETE flag), but I still don't know if it can be used for system files.
I'm sure windows could be fixed so that parts could be restarted, but it would be a major project that would take years. But they probably won't do it since every windows system in a large deployment is part of a cluster of servers, so one going down for a reboot isn't much of a hassle. It's where you don't have a cluster that it is a problem.
Thanks, I didn't know about this...
The first hit on google brings up: Use FILE_SHARE_DELETE in your shell extension
Here's an interesting quote:
In the CreateFile() call that opens the file, use FILE_SHARE_READ | FILE_SHARE_DELETE in the dwShareMode parameter.
The MSDN documentation doesn't make it clear at all, but FILE_SHARE_DELETE works with MoveFile() in the same way it does with DeleteFile(). In other words, it gives you Unix-style delete/rename semantics. Even while you have the file open, Windows can delete it or rename it right out from under you, but you can keep reading it--your handle to the file remains valid until you close it.
So, in the case above, Windows moves the file to the destination folder without interference from your thumbnail code.
Mike Mascari ran a test of this and posted the results in the comp.databases.postgresql.hackers newsgroup:
Well, here's the test:
foo.txt contains "This is FOO!"
bar.txt contains "This is BAR!"
Process 1 opens foo.txt
Process 2 opens foo.txt
Process 1 sleeps 7.5 seconds
Process 2 sleeps 15 seconds
Process 1 uses MoveFile() to rename "foo.txt" to "foo2.txt"
Process 1 uses MoveFile() to rename "bar.txt" to "foo.txt"
Process 1 uses DeleteFile() to remove "foo2.txt"
Process 2 awakens and displays "This is FOO!"
On the filesystem, we then have:
foo.txt containing "This is BAR!"
The good news is that this works fine under NT 4 using just MoveFile(). The bad news is that it requires the files be opened using CreateFile() with the FILE_SHARE_DELETE flag set. The C library which ships with Visual C++ 6 ultimately calls CreateFile() via fopen() but with no opportunity through the standard C library routines to use the FILE_SHARE_DELETE flag. And the FILE_SHARE_DELETE flag cannot be used under Windows 95/98 (Bad Parameter). Which means, on those platforms, there still doesn't appear to be a solution. Under NT/XP/2K, AllocateFile() will have to modified to call CreateFile() instead of fopen(). I'm not sure about ME, but I suspect it behaves similarly to 95/98.
I would immagine that it was inherited from somewhere else, either VMS or the other family tree of windows for compatability. Hopefully someone who does know will point it out...
One of the nice things about the windows semantics of "can't have two writers" is that programs can test for writability to see if someone else has the file open for write. This is used by word to keep two people writing to a file while another has it open. It also cuts into flexability as my origional post shows.
In the unix world, all locking is at the application level and nothing prevents someone else modifying a file you have open (as long as they have write permission of course). So there is greater flexability and greater ability to shoot your whole foot off, instead of just shoot yourself in the foot.
See the Mozilla Relicensing FAQ
How will the new Mozilla license scheme affect developers who want to use Mozilla code in creating and distributing proprietary applications?
Not at all; developers creating and distributing proprietary software incorporating Mozilla code will be able to continue to use that code under MPL terms and conditions, exactly as they have been doing all along.
The MPL was originally designed to allow source files distributed under MPL terms to be combined with source files under other licenses, and the resulting work to be distributed under a non-MPL license. (This right is contingent on the requirements of the MPL being fulfilled. For example, when distributing the resulting work to users, the distributor must also make available to users the source code for that portion of the code created from the source files distributed under the MPL.)
This feature of the MPL has allowed developers to distribute proprietary products incorporating Mozilla code. (Netscape 7 is one example of such a product.) Under the MPL/GPL/LGPL triple license scheme developers may continue to create and distribute Mozilla-based proprietary products, by taking advantage of the option to use the Mozilla code under the MPL terms and complying with the various requirements of the MPL for those portions of the proprietary products based on Mozilla code.
(In theory developers could also distribute Mozilla-based proprietary products using the Mozilla code under LGPL terms, if the Mozilla code were in the form of a library and the developers complied with the relevant requirements of the LGPL.)
So many are worried about germs.
This is worse than a toilet seat! You might catch a virus or something...
For short distances, yes.
But not when you're going several miles.
One thing that doesn't mix well with cycling is nice clothes, and making a good impression upon arival.
You are sweaty and so are your clothes unless you bring a change of clothes when you get to work.
Having been in a car accident recently and being carless (didn't have insurance at the time...) I have been walking a little over 1 mile each direction to work. I have lost weight, and I find that while I do sweat, it is much lighter than when I used to cycle where it was mostly from the main sweat producing glands (arm pits, back (mostly from the backpack), and chest).
What do other areas require?
If it cut into my business, I would immediately switch to another ISP and sue the origional ISP for damages if I could.
Why leave it up? Because if you don't you customer can sue you if it weren't for the TOS.
Why take it down? Because the "copyright holder" can sue you and you TOS can't help you there.
If an image of the rendered page was made available instead that would be acceptable to be called an "example meant to warn".
"Thats all fine and dandy, but doesnt' change the fact winodws still needs to be rebooted:)"
I was showing why windows will never be able to catch up in requiring as few reboots as unix OSes. If you didn't catch that, please read my previous post again, it was kinda long...
"And says windows is useing an outdated not so good filesystem."
Why do you say that?
NTFS supports all of the unix sematics natively. In fact, everything is a file -- even directories and "inodes".
You have a combined inode list and journal in the MFT file.
(in fact, the design of ext2 and 3 keeps the inodes close to the data with block groups spread out over the disk. (these block groups also provide a level of backup information that that helps greatly during filesystem recovery on bad disks -- but you have backups, right?)
So, if you implement NTFS so that the MFT file is intentionally fragmented to put the inode data close to the data blocks, you could have the same performance advantages ext2/3 does for reads on large files (I'm not sure what XFS does to get its speed advantages though). Or whatever else might be a better layout. But you wouldn't have the recovery advantages of ext2/3's block groups though.)
If the FLOSS community could just fork NTFS from the specs published before microsoft changed the FS and didn't publish the specs, NTFS could be one of the premiere filesystems in Linux. But alas, NTFS support in Linux and OSX is not about optimizing for production use, but for compatability with windows systems.
Fragmentation can be overcome by a better implementation like Suse's enhancements to ReiserFS does in the 2.6 kernel. (Did that make it in yet? I haven't been following LKML for the last several months.)
Just like ext2/3 for windows might not be as reliable because it might not follow the same integrity procedures that the linux kernel implementation does -- almost by requirement since since Linux's ext2/3 implementation is gpl, and I don't believe the MS FS SDK is gpl compatible.
"* I know. But OS X is not Unix, never has been, and probably never will be. I'll believe it's Unix whe the Open Group tell me it is."
Neither is Linux.
And the new extensions coming out in Xorg seems to allow the features of quartz in X. Maybe some day quartz will just be an abstraction layer to X + extensions.
Apple has created several proprietary parts where there weren't standard parts, but are surprisingly open for a non-linux company.
I'm not an OSX wizard, but finding out that the software raid on OSX only works with entire drives is an artificial limitation. I don't know what it does for LVM either.
It isn't the integration that causes requirements for reboots.
It's the base concept of not being able to move or rename a file once it is open. This is the same whether you are talking about a simple text file, or your system files for the OS.
Most filesystems (fat, ntfs, and of course all unix filesystems) have an abstraction between a directory entry, and a filesystem wide number that identifies a file -- in unix filesystem terminology that is the "inode". The problem is that windows does not use that natural abstraction.
In unix, if a program has a file open, you can "delete" that file -- wait it's not gone yet[1]. What happens under the covers, is that your filename in a directory points to an inode. Each inode has a count of the number of references to itself. When you open the file that reference count for the inode is incremented. So if there is one program with the file open, and the inode is referenced in one directory, the reference count is now two. Once that count goes to zero, the inode is unlinked -- which means deleted, but since "delete" is multi-step in unix, you need more terms.
[1] This is a great way to work with temporary files -- once you open and delete it, nobody else can access the file and many security threats with temp files are completely avoided.
Now you have a system file that needs updating. You delete the file (which just removes one reference from the directory) and the system still holds a reference to the inode and continues operating as before. Then, you write the new updated file to the same directory with the same name, but it doesn't cause a conflict because the new file goes into a different inode. Once the files are replaced, restart the individual application and the update is finished.
On windows, to update a system file that can not be closed during the operation of the system, you put the files in a special location with a script that specifies their desired location. Every time windows boots it runs those scripts that replaces files before they are opened. That is why windows will always require more reboots than unix based OSes.
There is more to updating system files than that of couse. For instance, most unix servers do not run a graphical environment on the server and every version of windows since NT boots into a graphical graphical environment. Most Unix based systems use the Xwindows system for their graphical environment, and an update to that environment only requires a restart of Xwindows not the entire system -- which is important if you are running any services on your computer that people depend upon.
Yes, this is exactly the meaning behind my origional post.
Charging is for people who are annoyed by their friends/family that constantly ask you to fix their systems, and refuse to do it for themself. If that doesn't bother you, then don't charge them. It's that simple.
Work with them? Hell I am one!
I would be a BOFH if I had the guts...
What? They only found out about zero day holes recently?!
Ever heard of a one night stand?
Nevermind, wrong site...
"Microsoft attempts to destroy all browsers in new version of Windows by causing them to make farting sounds every time you visit a web site."
Oooh, even better do that with IE!
What a better way to keep workers from using it -- emberass them!
Another benefit of a VIA processor is that they keep up with the instruction set advancements of Intel and AMD.
Before you start adding a lot of extra error reporting, it should be designed in such a way that it will be extendable in the future so that you don't end up with an unmanagable error reporting system.