Windopes abject failure with NTFS filesystem
7
> Linux failed to repair my borked NTFS partition. Commercial Windows
> software came to the rescue and gave me back all my vacation pics.
In other words windopes that created the NTFS partition had suffered
ABJECT FAILURE and YOU could not repair it with windopes.
YOU had to rely on third parties to fix abject failure of windopes OS
and its NTFS filesystem!!!
Its something you don't encounter with GNU/Linux filesystems!
Because GNU/Linux filesystems
a. rarely fails
b. there are tools in GNU/Linux recover filesystem damage
c. there are tools in GNU/Linux to recover partition table damage
OK
<website_...@www.ecu.pwp.blueyonder.co.uk> wrote:
>Mike Cox wrote:
>
>> Linux failed to repair my borked NTFS partition. Commercial Windows
>> software came to the rescue and gave me back all my vacation pics.
>
>
>
>In other words windopes that created the NTFS partition had suffered
>ABJECT FAILURE and YOU could not repair it with windopes.
>YOU had to rely on third parties to fix abject failure of windopes OS
>and its NTFS filesystem!!!
>
>Its something you don't encounter with GNU/Linux filesystems!
>
>Because GNU/Linux filesystems
>a. rarely fails
Just pull the power plug on ext2
Beowulf TrollsHammer
>
> Just pull the power plug on ext2
>
Who's still using ext2 nowadays?
Peter Köhlmann
Lots and lots of people
All who use ext3, for example, as ext2 is the underlying fs
Robert Newson
> On Sat, 21 May 2005 10:24:22 GMT, 7
> <website_...@www.ecu.pwp.blueyonder.co.uk> wrote:
...
>>Because GNU/Linux filesystems
>>a. rarely fails
>
> Just pull the power plug on ext2
And?
I've had power failures in the past to my linux box which had ext2 on it and
it recovered fine. (ps problem finally traced to a dodgy power supply switch.)
Linønut
>>Because GNU/Linux filesystems
>>a. rarely fails
>
> Just pull the power plug on ext2
I've done that quite a few times (in the past). No problem.
A quick fsck at the next boot.
--
When all you have is a hammer, everything looks like a nail.
Alexander Skwar
> Who's still using ext2 nowadays?
Me. For /boot. But /boot isn't mounted, normally.
Alexander Skwar
--
Free Software: the Software by the People, of the People and for the People.
Develop! Share! Enhance! and Enjoy!
-- Andy Tai
Peter Jensen
Hash: SHA1
Peter Köhlmann wrote:
>>> Just pull the power plug on ext2
>>
>> Who's still using ext2 nowadays?
>
> Lots and lots of people
> All who use ext3, for example, as ext2 is the underlying fs
So they *aren't* using ext2, because they're using ext3 instead. And
pulling the plug on an ext3 system isn't nearly as harmful as pulling it
on an ext2 system.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFCkGUBd1ZThqotgfgRApZaAKCibzfhT8csSqSBEgobMSBoHzu+hQCeMLmg
i842CAzuZWX7X8a/eg9zDfI=
=KhWc
-----END PGP SIGNATURE-----
--
PeKaJe
<spyderous> thanks luca. remind me never to go to a hooter's web site
again, it freezes my sex-deprived computer.
Peter Köhlmann
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Peter Köhlmann wrote:
>
>>>> Just pull the power plug on ext2
>>>
>>> Who's still using ext2 nowadays?
>>
>> Lots and lots of people
>> All who use ext3, for example, as ext2 is the underlying fs
>
> So they *aren't* using ext2, because they're using ext3 instead. And
> pulling the plug on an ext3 system isn't nearly as harmful as pulling it
> on an ext2 system.
>
You aree aware that you can mount a ext3 fs just as well as ext2?
ext3 is actually ext2 with the journal glued on top
Peter Jensen
Peter Köhlmann wrote:
I'm perfectly aware of that, but I still don't think you can say that
people are using an ext2 system when they're actually using the journal,
thus making it an ext3 system. The processing in the kernel is handled
differently, and you don't need support for one in order to use the
other. VFAT also builds on standard FAT, but with some hacks to enable
long file name support. That doesn't make a VFAT system a FAT system.
Can we at least agree that very few people today use ext2 systems that
are actually mounted as such?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFCkJ34d1ZThqotgfgRAiFeAJ4tPrO+lg2MmVBWX7iXJ3k3CqG9UACffLyO
2lW17Mp8SE4OvuT2XPi8IHs=
=Bo6W
-----END PGP SIGNATURE-----
--
PeKaJe
BOFH Excuse #441:
Hash table has woodworm
Donn Miller
I typically use it as my minimal /boot partition, which doesn't get
mounted after boot.
----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Donn Miller
Ext2 has some more potential as well. For example, it's basically very
much like a UFS filesystem, but without fragmentation. Someone
mentioned implementing fragmentation. Another idea was to implement a
softupdates-like system for ext2. Don't know if that ever got
implemented or not.
Roy Culley
<4290a264$1...@spool9-west.superfeed.net>,
Donn Miller <hac...@yahoo.com> writes:
> Peter Köhlmann wrote:
>
>> You aree aware that you can mount a ext3 fs just as well as ext2?
>> ext3 is actually ext2 with the journal glued on top
>
> Ext2 has some more potential as well. For example, it's basically
> very much like a UFS filesystem, but without fragmentation. Someone
> mentioned implementing fragmentation.
I presume by fragmentation you mean where a logical disk block could
be used to store several small files instead of allocating a logical
disk block to each of them? Don't want the Windows people to think it
has anything to do with the fragmentation their filesystems have and
that need special utilities to unfragment.
Jim
I'd like to correct you, if I could. Fragmentation is where a file is
broken across several non-contiguous blocks. This is unavoidable,
happens on /every/ filesystem, each of which deals with file
fragmentation in its own way - some defragment in the background, some
grind slowly to a halt. When a single block is used for several files
(actually, more than /one/ file), said block is /crosslinked/. As far as
the kernel is concerned, the contents of that block is a single piece of
data, referenced by several entries in the FAT, and (probably)
irretrievable. This can be a Very Bad Thing if the crosslinking occurs
with system-critical files, such as the boot sector, or with mission
critical user files.
--
Cheers,
Jim
-begin sig-
Opinions expressed in this message may or may not be representative of
the opinions of its author. You decide.
Web: http://www.dotware.co.uk
http://www.dotware-entertainment.co.uk
Drool factor removed to save screen inches.
-end sig-
Roy Culley
<j45ke.13100$f5.1...@newsfe6-win.ntli.net>,
Jim <ja...@the-computer-shop.co.uk> writes:
> Roy Culley wrote:
>> begin risky.vbs
>> <4290a264$1...@spool9-west.superfeed.net>,
>> Donn Miller <hac...@yahoo.com> writes:
>>>Peter Köhlmann wrote:
>>>
>>>>You aree aware that you can mount a ext3 fs just as well as ext2?
>>>>ext3 is actually ext2 with the journal glued on top
>>>
>>>Ext2 has some more potential as well. For example, it's basically
>>>very much like a UFS filesystem, but without fragmentation. Someone
>>>mentioned implementing fragmentation.
>>
>> I presume by fragmentation you mean where a logical disk block could
>> be used to store several small files instead of allocating a logical
>> disk block to each of them? Don't want the Windows people to think it
>> has anything to do with the fragmentation their filesystems have and
>> that need special utilities to unfragment.
>
> I'd like to correct you, if I could. Fragmentation is where a file is
> broken across several non-contiguous blocks.
No, I was asking if Donn was referring to BSD 4.3 (possibly earlier)
fragments. This avoids wastage of disk space for small files. Although
the disks may have a block size of 512 bytes for example the
filesystem uses larger logical block sizes, 4096 bytes for example. On
BSD these logical blocks would use fragments for small files. Thus
more than one small file would use up only a single logical block thus
saving disk space.
I know this type of fragmentation is different to what most people
refer to as fragmentation these days so that is why I asked Donn to
clarify.
An excellent book if you want to learn more is 'The Design and
Implementation of the 4.3BSD Unix Operating System' which explains
fragments and loads of other stuff.
Jim
ah, filesystem compression. With you.
Robert Newson
...
> ah, filesystem compression. With you.
You'll now get windopes thinking that BSD has inbuilt fs compression like
Windows has compressed drives where the data is [de]compressed on the fly
between system and disk drive.
There is two types of fragmentation in a file system: file fragmentation and
block fragmentation.
When people refer to fragmentation of a file system, they generally mean the
first: file fragmentation - whereby the blocks used by a file are splattered
over the disk in an in-optimum arrangement (usually a bad thing, hence fat
has a defragmentor to re-arrange these clusters/blocks).
BSD designed a block fragmentation to utilise disk space when there are lots
of small files, or files that just go into another block to finish - what it
does is split a block (or cluster in fat/MSDOS/Windows terminology) up so
that more than one file can reside in that disk space:
"A major principle in 4.2 BSD file system implementation is that the more
data the kernel can access on the disk in a single operation, the faster the
access becomes. That argues for larger logical disk blocks, and the
Berkeley implementation allows blocks of 4K or 8K bytes. But having larger
block sizes on disk increases block fragmentation, leaving large portions of
disk space unused[1]. For instance, if the logical block size is 8K bytes,
then a file of size 12K bytes uses 1 complete block and half a second block.
The other half of the second block is wasted; no other file can use the
space for data storage...the amount of wasted disk space can be as high as
45% for a file system with logical blocks of size 4K bytes. The Berkeley
implementation remedies the situation by allocating a block _fragment_ to
contain the last data in a file. One disk block can contain fragments
belonging to several files." (Design of the Unix OS, ISBN : 0-13-201757-1)
[1] (My comment) This was(/is) a major problem for MSDOS & fat16: as the
partition size grew, the cluster (logical block) size had to grow to address
the disk space, and so all the original Windows *.INI files of a few bytes
were suddenly wasting huge amounts of disk space - unless the partition size
was kept small so that the cluse size was small. *nix config files are
typically <1K (or even <128bytes), and so a lot of disk space can be wasted
- here BSD comes to the rescue.
OK
And?? As far as I know there is no journal on ext2 and as a result
what happens to your volume(s) on a sudden power failure is pretty
much left to chance.
Noah Roberts
> And?? As far as I know there is no journal on ext2 and as a result
> what happens to your volume(s) on a sudden power failure is pretty
> much left to chance.
>
10 years ago or so I had my ext2 take a shit because the power was
turned off during an fsck. Many power failures have occured since then
that did not cause failure of the FS. It is very rare for the FS to
*fail*. What can and often will happen is loss of data. 99% of the
time the filesystem is still left in a fully functional state even if
some files that were being altered are ruined.
OK
If occasionally ruining files is okay then I guess we don't have the
same definition of "failure". NTFS never does that to you.
Peter Köhlmann
It doesn't?
It did 2 times to my files
Linønut
> If occasionally ruining files is okay then I guess we don't have the
> same definition of "failure". NTFS never does that to you.
Given that Windows experiences odd behavior now and then anyway, how
would you know if NTFS fscked-up (pun intended) a system file or two
after an involuntary power outage?
John Winters
OK <ot...@keiser.de> wrote:
[snip]
>If occasionally ruining files is okay then I guess we don't have the
>same definition of "failure". NTFS never does that to you.
ROTFL! Clearly you don't have much experience of NTFS.
Clue - this whole thread started because the OP was trying to recover
a hosed NTFS file system.
HTH
John
--
Wallingford, Oxfordshire, England
i = (free(NULL), i++);
Peter Jensen
Hash: SHA1
OK wrote:
>> 10 years ago or so I had my ext2 take a shit because the power was
>> turned off during an fsck. Many power failures have occured since
>> then that did not cause failure of the FS. It is very rare for the
>> FS to *fail*. What can and often will happen is loss of data. 99%
>> of the time the filesystem is still left in a fully functional state
>> even if some files that were being altered are ruined.
>
> If occasionally ruining files is okay then I guess we don't have the
> same definition of "failure". NTFS never does that to you.
You deliberately compare ext2 with NTFS, despite the fact that NTFS is
journaled. If you want to make a *fair* comparison (I know you don't,
you're clearly a troll), at least compare NTFS with ext3. Oh, and NTFS
quite regularly hoses files, which this whole thread is evidence of.
I've only once or twice heard about that happening to ext3 for reasons
other than hardware failure.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFCk1oId1ZThqotgfgRAsJOAJ9x4fz+GUSU2etOTMdfHLoQ+mIkfACgyLr0
a+Au3qc1S8SaIO7tvhlO2Iw=
=rcxI
-----END PGP SIGNATURE-----
--
PeKaJe
Windows, reboot. Linux, be root!
Peter Jensen
Hash: SHA1
OK wrote:
>>> Just pull the power plug on ext2
>>
>> And?
>>
>> I've had power failures in the past to my linux box which had ext2 on
>> it and it recovered fine. (ps problem finally traced to a dodgy
>> power supply switch.)
>
> And?? As far as I know there is no journal on ext2 and as a result
> what happens to your volume(s) on a sudden power failure is pretty
> much left to chance.
Yes, and that's why just about nobody uses ext2 for their data
partitions these days. They use ext3 or some other journaled file
system instead. You're trying to make it sound like Linux file systems
are dangerous to your data by pretending that only ext2 exists. Very
trollish of you.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFCk1r9d1ZThqotgfgRAooLAJ42kjSN4NiAMrq7fuYn3zyfXLDhOACeOCvE
nrsH61StHDhmnl8Bl54tAqc=
=jw7c
-----END PGP SIGNATURE-----
--
PeKaJe
Sit back and watch the messages. This is actually more important than one
might think as there is a bug in GNU Mach whereby hitting a key during the
boot process causes the kernel to panic -- GNU Hurd Installation Guide
DFS
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> OK wrote:
>
>>> 10 years ago or so I had my ext2 take a shit because the power was
>>> turned off during an fsck. Many power failures have occured since
>>> then that did not cause failure of the FS. It is very rare for the
>>> FS to *fail*. What can and often will happen is loss of data. 99%
>>> of the time the filesystem is still left in a fully functional state
>>> even if some files that were being altered are ruined.
>>
>> If occasionally ruining files is okay then I guess we don't have the
>> same definition of "failure". NTFS never does that to you.
>
> You deliberately compare ext2 with NTFS, despite the fact that NTFS is
> journaled. If you want to make a *fair* comparison (I know you don't,
> you're clearly a troll), at least compare NTFS with ext3. Oh, and
> NTFS quite regularly hoses files,
Prove it.
William Poaster
DFS was seen to write:
> Peter Jensen wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> OK wrote:
>>
>>>> 10 years ago or so I had my ext2 take a shit because the power was
>>>> turned off during an fsck. Many power failures have occured since
>>>> then that did not cause failure of the FS. It is very rare for the FS
>>>> to *fail*. What can and often will happen is loss of data. 99% of
>>>> the time the filesystem is still left in a fully functional state even
>>>> if some files that were being altered are ruined.
>>>
>>> If occasionally ruining files is okay then I guess we don't have the
>>> same definition of "failure". NTFS never does that to you.
>>
>> You deliberately compare ext2 with NTFS, despite the fact that NTFS is
>> journaled. If you want to make a *fair* comparison (I know you don't,
>> you're clearly a troll), at least compare NTFS with ext3. Oh, and NTFS
>> quite regularly hoses files,
>
> Prove it.
We don't need to prove you're a troll, you do it with every post.
--
With GPL the only thing Microsoft
gets for free is nightmares.
-- Jean Francois Martinez --
Peter Jensen
Hash: SHA1
DFS wrote:
>> Oh, and NTFS quite regularly hoses files,
>
> Prove it.
I've had it happen to me, I've seen it happen on at least two other
systems, and even your fellow troll who started the original thread has
experienced it (and apparently saw it as a failure of Linux because it
couldn't repair it, how pathetic is that as a trolling subject?).
Circumstantial evidence, I know, but I think you'll find that NTFS hoses
file systems quite a bit more often than ext3. You're welcome to find
evidence to contradict my claim that ext3 is significantly more stable
than NTFS, but I suspect you won't find any.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFCk3rdd1ZThqotgfgRAlgHAJ9S86kndxNp2sO+B2FTNeibSYPxlgCfZ70v
gfWeLwpz+D+HCCKi9v09Xbk=
=OOv+
-----END PGP SIGNATURE-----
--
PeKaJe
I'm going to Vietnam at the request of the White House. President
Johnson says a war isn't really a war without my jokes. -- Bob Hope
Ku Karlovsky
(<d6vd9d$73r$1...@bletchley.home.sinodun.org.uk>) wrote:
> ROTFL!
Hey, ROTFLboi!
>
> Clue - this whole thread started because the OP was trying to recover
> a hosed NTFS file system.
Corrected Clue - this whole thread started because the OP was
trolling.
> HTH
No, it didn't help. Your analysis was wrong.
DFS
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> DFS wrote:
>
>>> Oh, and NTFS quite regularly hoses files,
>>
>> Prove it.
>
> I've had it happen to me, I've seen it happen on at least two other
> systems, and even your fellow troll who started the original thread
> has experienced it
So, 4 instances is all you have? And that's "quite regularly"? And
surprise - you're a Linux "advocate". Figures.
(once again, everything a Linux user says about Windows must be treated as
false until it can be verified. In your case, it can't.)
> (and apparently saw it as a failure of Linux
> because it couldn't repair it, how pathetic is that as a trolling
> subject?).
Pretty weak, I agree.
> Circumstantial evidence, I know, but I think you'll find
> that NTFS hoses file systems quite a bit more often than ext3.
Where will I find that?
> You're welcome to find evidence to contradict my claim that ext3 is
> significantly more stable than NTFS, but I suspect you won't find any.
Maybe not. Maybe. Googling on "corrupt ext3" provides far more
user-proportional hits than "corrupt NTFS".
And it's clear your lie that NTFS "quite regularly hoses files" can't be
supported.
John Bailo
> Maybe not. Maybe. Googling on "corrupt ext3" provides far more
> user-proportional hits than "corrupt NTFS".
>
> And it's clear your lie that NTFS "quite regularly hoses files" can't be
> supported.
>
"Missing or corrupt Ntfs.sys" error message when you restart Windows XP
after you convert your hard disk to the NTFS file system
http://support.microsoft.com/default.aspx?scid=kb;en-us;822800
CAUSE
This problem may occur if the Ntfs.sys file is missing or becomes
corrupted when you convert your hard disk to NTFS.
--
Texeme Textcasting Technology
http://texeme.com
Peter Jensen
Hash: SHA1
DFS wrote:
>> I've had it happen to me, I've seen it happen on at least two other
>> systems, and even your fellow troll who started the original thread
>> has experienced it
>
> So, 4 instances is all you have? And that's "quite regularly"?
Considering that I don't deal with many Windows machines, yes. And
that's just what *I* have come across with first-hand reports. The only
times I've heard of ext3 corruption was on Usenet (I think) from someone
I don't know personally. It may have had something to do with a bug
that was briefly in the 2.4 kernel at some point, I don't remember.
Quite fixable, of course.
> And surprise - you're a Linux "advocate". Figures.
And you're completely unbiased, right? I guess it doesn't matter what I
say, or how much evidence I present, you'll just discard it because I'm
a Linux advocate. I'm just not going to bother with you any more.
> (once again, everything a Linux user says about Windows must be
> treated as false until it can be verified. In your case, it can't.)
How would you like me to prove it? All I have is what people have told
me and what I have experienced myself. I guess it comes down to your
word against mine, but I think I have more credibility in the grand
scheme of things.
>> (and apparently saw it as a failure of Linux because it couldn't
>> repair it, how pathetic is that as a trolling subject?).
>
> Pretty weak, I agree.
*blink* ... OK, that's a rarity ... Still, I would have been surprised
if anyone thought Mike actually had a point here. It's just too far out
there.
>> Circumstantial evidence, I know, but I think you'll find that NTFS
>> hoses file systems quite a bit more often than ext3.
>
> Where will I find that?
OK, I guess you're not the computer-person people always consult when
things go wrong. I, however, am such a person, and I've come across
relatively many such NTFS corruptions.
>> You're welcome to find evidence to contradict my claim that ext3 is
>> significantly more stable than NTFS, but I suspect you won't find
>> any.
>
> Maybe not. Maybe. Googling on "corrupt ext3" provides far more
> user-proportional hits than "corrupt NTFS".
I think you know just how little a Google hit-meter means (which just
goes to further discredit you). Particularly for something like this.
You do know that in the OSS world people (both users and developers) use
the Internet a lot to talk back and forth about any and all problems and
how to solve them, right? So it stands to reason that there will be
proportionally many more hits for ext3 problems because talking about it
can actually solve the problem. If the NTFS handling has a bug in it,
it never leaves Microsoft, and you never see anything about it on
Google. Any bugs in Linux are, on the other hand, quite publicly
displayed.
Now can you actually dig up a single recent case of ext3 corruption that
wasn't caused by failing hardware?
> And it's clear your lie that NTFS "quite regularly hoses files" can't
> be supported.
It's not a lie until you've proved me wrong with facts. It's my
*opinion* of NTFS, backed by past experience. I thought I had made that
clear.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFCk48Qd1ZThqotgfgRAsrRAJ4pNpb9wxfJa7duvL9v1YErF4ZTYACgzN9G
4ahbVlGZ5HQLLR1w0a4JanE=
=0GDG
-----END PGP SIGNATURE-----
--
PeKaJe
"Of all the tyrannies that affect mankind, tyranny in religion is the
worst." -- Thomas Paine
The Ghost In The Machine
<nos...@dfs.com>
wrote
on Tue, 24 May 2005 13:29:49 -0400
> Peter Jensen wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> OK wrote:
>>
>>>> 10 years ago or so I had my ext2 take a shit because the power was
>>>> turned off during an fsck. Many power failures have occured since
>>>> then that did not cause failure of the FS. It is very rare for the
>>>> FS to *fail*. What can and often will happen is loss of data. 99%
>>>> of the time the filesystem is still left in a fully functional state
>>>> even if some files that were being altered are ruined.
>>>
>>> If occasionally ruining files is okay then I guess we don't have the
>>> same definition of "failure". NTFS never does that to you.
>>
>> You deliberately compare ext2 with NTFS, despite the fact that NTFS is
>> journaled. If you want to make a *fair* comparison (I know you don't,
>> you're clearly a troll), at least compare NTFS with ext3. Oh, and
>> NTFS quite regularly hoses files,
>
> Prove it.
One cannot prove that NTFS hoses files. One might be able to show
significant instances where NTFS, or some application using
such, decided to do something very dumb with files, perhaps.
But without the source code, how do we tell?
The best I can supply here is that, when using Java and compiling
.java source files into .class files where both are on an NTFS
volume mounted remotely on Linux (using "mount -t smbfs"), that
on occasion one of the internal class files gets either junked
or confused to the extent that the resulting .jar file won't load,
or the application won't run.
If one declares a class such as TestMe.java:
public void TestMe {
public static void main(String[] args)
{
Thread t = new Thread(new Runnable() {
public void run() { ... }
});
t.start();
}
}
the internal class (an anonymous affair which implements the
Runnable interface) shows up as TestMe$1.class, if I'm not mistaken.
However, there are multiple suspects here:
[1] Linux is mounting Windows NTFS sites remotely. That's a big "if"
right there, although Linux is probably better at it than Microsoft
at this point. :-) (At least, that's the feeling I get.)
[2] Java does some interesting internal stuff using threads. Perhaps
there's an issue while it's saving the .class files during compilation?
[3] NTFS is certainly a suspect here, but not the only one. One thing
against NTFS is that it is case-preserving rather than
case-sensitive -- but that wouldn't by itself cause files to
vanish unless Java was doing something extremely stupid, like
creating the temporary file tESTmE$1.CLASS then renaming it
when it's done to TestMe$1.class.
[4] Java, when reading things back in, might misinterpret something
from NTFS, Samba code, or both.
Eenie meanie mienie mo...
[rest snipped]
--
#191, ewi...@earthlink.net
It's still legal to go .sigless.
Peter Köhlmann
< snip >
>> And it's clear your lie that NTFS "quite regularly hoses files" can't
>> be supported.
>
> It's not a lie until you've proved me wrong with facts. It's my
> *opinion* of NTFS, backed by past experience. I thought I had made that
> clear.
>
It is mine too, since I have had two crashes of windows with corrupt NTFS
Both on the same machine, with dual processor, ECC Ram and SCSI disks
It was completely unrecoverable both times, meaning I would have lost all
files if I had not used backups every other day. So I lost actually little,
except quite some time
After the second incidence, linux was installed. It never crashed again,
with anything at all. But then, I knew the hardware wasn't faulty
Jim
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> DFS wrote:
>
>
>>>Oh, and NTFS quite regularly hoses files,
>>
>>Prove it.
>
>
> I've had it happen to me, I've seen it happen on at least two other
> systems, and even your fellow troll who started the original thread has
> experienced it (and apparently saw it as a failure of Linux because it
> couldn't repair it, how pathetic is that as a trolling subject?).
> Circumstantial evidence, I know, but I think you'll find that NTFS hoses
> file systems quite a bit more often than ext3. You're welcome to find
> evidence to contradict my claim that ext3 is significantly more stable
> than NTFS, but I suspect you won't find any.
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
>
> iD8DBQFCk3rdd1ZThqotgfgRAlgHAJ9S86kndxNp2sO+B2FTNeibSYPxlgCfZ70v
> gfWeLwpz+D+HCCKi9v09Xbk=
> =OOv+
> -----END PGP SIGNATURE-----
A few years ago, I installed Windows 2000 Pro on one of my systems
(specifically, a fileserver), which already contained three data drives
formatted to NTFS. The first post-install boot, the thing went into
chkdsk mode and hosed /all three/ filesystems. I couldn't recover any of
them. Said bye bye to nearly 60GB of data. That Windows CD was burnt to
a crisp five minutes later, and on went Slackware 8 and the drives
reformatted to ext2. That server's still chugging away behind a drywall
somewhere...
--
Cheers,
Jim
-begin sig-
Opinions expressed in this message may or may not be representative of
the opinions of its author. You decide.
This is a battle of wits, and it is clear you are unarmed.
-end sig-
Noah Roberts
> If occasionally ruining files is okay then I guess we don't have the
> same definition of "failure". NTFS never does that to you.
In my experience it doesn't even require a power outage during a write
to cause file corruption on NTFS. Your experience must differ.