For off Windows XP machines offer several options - including hibernate, stand by and shut down. However, many users don't know the difference. What's worse, however, is that applications and drivers can veto a user's decision to hibernate or similar. In Vista however, applications will be warned that a computer is entering sleep and have a second or two to save what ever they need to, but the programs won't get a say in whether the machine slumbers.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:OK...one addition.
If they were using Captive -- the Microsoft NTFS drivers running under Linux from a wrapper -- the file system should not have rolled back any system edits.
If they used the Linux kernel NTFS drivers, no such luck. Since NTFS is not documented, the Linux drivers aren't fully compatable. The journal roll back that occurs is exactly what I'd expect when comming out of hibernation.
Member since:2005-07-06
You have no idea what you're talking about. Let's look at this in detail:
In Windows
1. File allocation table is in RAM
2. Some files are open, and expected to be in a certain state.
3. File seek points are in certain places.
4. File system is marked as dirty (not unmounted).
You hibernate Windows, and none of this changes. You then boot into Linux, and start making changes. Suddenly what Windows remembers in terms of a FAT table is wrong. Certain files might be changed that are still open over in Windows. Suddenly the data is in different places, and programs in Windows may crash the moment they try to work with an open file. Linux will try to correct the file system because it's been marked as dirty -- this can lead to any number of other problems.
The list goes on. You should NOT be using the same file system at the "same time" with two different operating systems, mounted twice. That is quite literally a braindead thing to do.
As for EXT3/NTFS ... yeah, they're journalled. Journalling doesn't prevent data loss, however, it just guarantees that the FS will always be in a consistent state.
Member since:2005-06-29
Poo makes some excellent points; excellent because he's right. You can't have hibernate and eat your dual boot cake too!
It'd be possible to solve these problems, but it'd involve a lot of work. The system would have to have a new signal for programs to support telling them to close out all their file handles: Anyone whose done any application coding can tell you what that'd mean for some programs.... Even if you got this to work; which would amaze me; it'd probably take as long as rebooting!
And whoever has been marking him down on this thread should have their voting capabilities removed or something. That's just rediculous. His name alone is not reason to vote him down guys!
Member since:You have no idea what you're talking about.
Yes, actually I do. Check my follow on message for additional details, though. In this case NTFS likely did the proper thing; it rolled back the modifications.
In Windows
1. File allocation table is in RAM
2. Some files are open, and expected to be in a certain state.
3. File seek points are in certain places.
4. File system is marked as dirty (not unmounted).
You hibernate Windows, and none of this changes.
Ah! So, it is a defect. Thanks for confirming what I already knew. (Or is it a defect? Well, not for the reason you just stated...maybe other reasons?)
The list goes on. You should NOT be using the same file system at the "same time" with two different operating systems, mounted twice. That is quite literally a braindead thing to do.
They didn't have two operating systems running at the same time using the file system. They hybernated...ran another OS...and restored from hybernation. If proper drivers were used (that is up for question), the state of the cache should be empty or the file system drivers were at fault.
Are they native Linux kernel drivers when booted under Linux? Were they wrapped Microsoft ones? Can't tell...doesn't seem like #2 (the preferred one)...so it may be the fault of the distro or the configuration and not Windows. Could go either way as far as I can tell.
Member since:I'd suggest you read about what "journaled filesystems" actually do: they keep the file *metadata* in a consistent recoverable state, by writing it twice: once at the start, in a journal area, and then once again, when it has been written into the final spot on the volume. This doesn't *not* apply to the regular data in the file! If a filesystem *did* do full journaling, even *that* would make the boneheaded assumption of being able to reboot to another system in the middle of hibernating the other one, doing anything other than perhaps read only operations, and then going back to the other one, bound to blow up the system that was hibernated in the first place, because of the *quite reasonable* assumption that the filesystem from one instant to the next won't be completely changed out from under the operating system that applications are running on.
Thus, NTFS, which has been a journaled filesystem since the beginning (available as of NT 3.1 back in 1993: I remember using it, personally, back then) does not have a flaw compared to EXT3, as it (EXT3) won't be any happier of an experience if you pull such a boneheaded manuever as modifying the filesystem in the middle of it being mounted within the context of a hibernation cycle.
Member since:2005-07-06
Member since:
Member since:
Member since:
This goes a lot deeper than just file caching. You would have to completely unmount the partition before being able to safely use it in another operating system. This isn't a "Microsoft bug", it's the nature of file systems, and every OS would suffer from this "limitation".
NTFS is supposed to be a journaling file system; if properly enabled, the file system should always be consistent or can be 'rolled back' to a consistent state.
EXT3 is a journaling file system. You can pull the plug under heavy load and it will be OK on the next boot.
So, no, this problem does not impact every OS.