tricked?

[Chuck]

Archived from groups: rec.games.roguelike.nethack (More info?)

Ken Cuvelier <kvcflameNO@SPAMyahoo.com> wrote in
news:115h3bc7fi4vb67@corp.supernews.com:

> chuck wrote:
>> re: the reply about write caching that you have received. I believe that
>> should be "write-behind" caching. You should make Sure that you have say
>> at least 2MB at least on the hard drive before you start playing if it
does
>> happen, as that is almost certainly the main cause. I am sure of this
because
>> I can repeatedly replicate a crash in linux as often as I like.
>
> To be completely accurate, on a Windows XP Home system with service pack
> 2, the policies tab that I directed xyblor to has the following wording
> next to the selection box: "Enable write caching on the disk."
>
> Apparently Microsoft decided at some point in time not to present the
> term "write-behind", although I agree that it is a better description of
> what actually takes place.
>
> -Ken


more dumbing down of microsoft software continues...

 

[Guest]

Archived from groups: rec.games.roguelike.nethack (More info?)

After going to <http://tinyurl.com/2tnqw>
chuck <chucko@nil.car> wrote

>"Boudewijn Waijers" <kroisos@REMOVETHISWORD.home.nl> wrote in
>news:d383di$lv0$1@news6.zwoll1.ov.home.nl:
>
>> The "line breaks" you're talking about are there, indeed. But those are
>> the line breaks inserted automatically at the end of the line. I wasn't
>> complaining that he posts single-line messages (which some people do). I
>> was trying to explain that dividing your message into paragraphs greatly
>> improves legibility.
>
>I think that may be a bit much. After all people express their thoughts
>differently and grammer is not something one can force on people is it?
>
>>>> Please see the FAQ for more tips on how to make your posts easier to
>I have still yet to see ANY faq. Am I mistaken in concluding there isn't one?

The subject line for the FAQ is:

rec.games.roguelike.nethack Frequently Asked Questions [FAQ]

And it got posted on March 26.
--
no, i didn't forget the 'F's
http://www.geocities.com/jerk_o2002
http://www.geocities.com/nameless_mod
-My Diablo 2 Mod
http://www.albinoblacksheep.com/flash/bunny.php
-My theme song

 

[Chuck]

Archived from groups: rec.games.roguelike.nethack (More info?)

j
> The subject line for the FAQ is:
>
> rec.games.roguelike.nethack Frequently Asked Questions [FAQ]
>
> And it got posted on March 26.

I just checked my isp and nada, then checked readfreenews and bingo. I will
peruse.

 

[Guest]

Archived from groups: rec.games.roguelike.nethack (More info?)

chuck wrote:
> I myself would not characterize a program crash as trickery, I would say
> trickery as something like making one step and being killed by a poison
> arrow.

No, trickery is if the game thinks the player cheats. Then it will end
itself and note in the score file, that the player died by trickery.
This is not a real crash.

> My understanding of the original poster's problem was that nethack
> itself crashed when he changed levels due to lack of disk space. I'm sure you
> will agree that those two concepts are unrelated. If the second poster meant
> a crash then there was a simantic (sp) difference that led to my
> misunderstanding of his meaning.

The OP died by trickery (that's why this thread's subject line is
"tricked") and so did xyblor.

--
If geiger counter does not click,
the coffee, she is just not thick

 

[Guest]

Archived from groups: rec.games.roguelike.nethack (More info?)

Dylan O'Donnell wrote:
> Klaus Kassner <Klaus.Kassner@physik.uni-magdeburg.de> writes:
>
>>xyblor wrote:

>>>scumming. Maybe this "feature" should be removed, since it's seems
>>>to be causing more trouble than benefits. And anyway, why would the
>>>game designers try to stop tampering of the game data that clearly
>>>takes place outside of game play?
>>
>>Yes, I think what the game should do in such a case is to simply
>>crash, leaving the playground files for recovery. Then one could use
>>recover to go back to the situation just before the level change.
>
>
> Umm. The point is that at least one of the playground files that
> recover would _use_ isn't viable; that's why the trickery's occurring
> in the first place.

In all the cases I had a trickery, it must have been the last level that
I entered that caused the problem. Going back to my save file from just
before changing levels I could continue playing as usual. The situation
was in no way different from an ordinary recovery, except that I was on
the level I had been before moving up or down the offending stairs. I
don't see why recovery should not work with using all the level files
that were not touched plus the one to which I changed in the form before
I changed to that level (since trickeries don't seem to happen when you
change to a *new* level, it will be a level that existed already).

That is almost what happens ordinarily when a game crashes and you use
recover. You are set to the beginning of the level on which it crashed.
In the case of a trickery, all that would have to be done to set you
back to the level *from* which you changed levels (which would mean that
the level you are loading should not be changed on disk, before loading
is successful and you have made your first move on the loaded level,
which I think is the case anyway; the level will only be rewritten once
you change to another one - and I believe the kind of trickeries I am
experiencing may be partially due to my changing to a new level before
the one from which I changed has been fully written, because they happen
predominantly when I change levels fast, like down-up-down-up - in order
to transport pets).

>>By the way, it is funny how the game reacts on a trickery in wizard
>>mode. You get the message "you are a very tricky wizard indeed", and
>>you can just continue playing...

> This is so you can debug just how unviable the level is It wouldn't
> be suitable for normal play.

I did not notice anything unusual on the "unviable" level. No debugging
was needed. Mind you, I don't think that real tampering with the
level files should be possible, so the trickery mechanism should work as
it does if something like that happens. However, what we see here is a
bug happening in the interaction of the game and some operating
system(s) (i.e. XP but probably not Linux).
--
Klaus Kassner

 

[Guest]

Archived from groups: rec.games.roguelike.nethack (More info?)

"chuck" <chucko@nil.car> wrote in message
news:Xns9633D9DB131A9chuckonilcar@207.35.177.135...

> I myself would not characterize a program crash as trickery, I would say
> trickery as something like making one step and being killed by a poison
> arrow. My understanding of the original poster's problem was that nethack
> itself crashed when he changed levels due to lack of disk space.

How would you infer that? Neither poster experienced a crash, both
experienced a similar problem, and yet you consider the two posts to be
unrelated?

> I'm sure you
> will agree that those two concepts are unrelated. If the second poster
> meant
> a crash then there was a simantic (sp) difference that led to my
> misunderstanding of his meaning.

I'm sure I'll not agree - both posters decribe the same "concept".

Having read both posts I would consider neither to be a crash, but both had
their games ended by trickery. He said that he's had a few games "ended" by
trickery, and he was replying to a thread about games ending in trickery. I
don't see where a "crash" comes into it.

D.

 

[Guest]

Archived from groups: rec.games.roguelike.nethack (More info?)

Klaus Kassner <Klaus.Kassner@physik.uni-magdeburg.de> writes:
> Dylan O'Donnell wrote:
>
> > This is so you can debug just how unviable the level is It wouldn't
> > be suitable for normal play.
>
> I did not notice anything unusual on the "unviable" level. No
> debugging was needed. Mind you, I don't think that real tampering
> with the level files should be possible, so the trickery mechanism
> should work as it does if something like that happens. However, what
> we see here is a bug happening in the interaction of the game and some
> operating system(s) (i.e. XP but probably not Linux).

How should the game distinguish between the two cases?

--
: Dylan O'Donnell http://www.spod-central.org/~psmith/ :
: "Peek-a-boo, I can't see you, everything must be grand; :
: Boo-ka-pee, you can't see me, as long as I've got me head in t'sand..." :
: -- Michael Flanders, "The Ostrich" :

 

[Chuck]

Archived from groups: rec.games.roguelike.nethack (More info?)

Sebastian Hungerecker <sepp00@web.de> wrote in news:d3amv3$iid$01$1@news.t-
online.com:

> No, trickery is if the game thinks the player cheats. Then it will end
> itself and note in the score file, that the player died by trickery.
> This is not a real crash.
I suggest you re-read the OP. The poster specifically says that the game
stopped when he changed levels with some message about levels not matching.
THAT is a crash The game did not exit cleanly which would be one of three
possiblities 1) saving 2) dieing 3) quiting The "trickery" involved if one
could characterize it as such would be the program not handling an
exceptional circumstance properly. or the short answer: if you have to
recover that is a crash.



>> My understanding of the original poster's problem was that nethack
>> itself crashed when he changed levels due to lack of disk space. I'm sure
you
>> will agree that those two concepts are unrelated. If the second poster
meant
>> a crash then there was a simantic (sp) difference that led to my
>> misunderstanding of his meaning.
>
> The OP died by trickery (that's why this thread's subject line is
> "tricked") and so did xyblor.
see above. Or better yet read my last message again, you aren't understanding
it.

 

[Chuck]

Archived from groups: rec.games.roguelike.nethack (More info?)

"Paul Dunn" <paul.dunn4@ntlworld.com> wrote in
news:iV96e.3602$C2.192@newsfe3-win.ntli.net:

>
> "chuck" <chucko@nil.car> wrote in message
> news:Xns9633D9DB131A9chuckonilcar@207.35.177.135...
>
>> I myself would not characterize a program crash as trickery, I would say
>> trickery as something like making one step and being killed by a poison
>> arrow. My understanding of the original poster's problem was that nethack
>> itself crashed when he changed levels due to lack of disk space.
>
> How would you infer that? Neither poster experienced a crash, both
> experienced a similar problem, and yet you consider the two posts to be
> unrelated?
>
>> I'm sure you
>> will agree that those two concepts are unrelated. If the second poster
>> meant
>> a crash then there was a simantic (sp) difference that led to my
>> misunderstanding of his meaning.
>
> I'm sure I'll not agree - both posters decribe the same "concept".
>
> Having read both posts I would consider neither to be a crash, but both had
> their games ended by trickery. He said that he's had a few games "ended" by
> trickery, and he was replying to a thread about games ending in trickery. I
> don't see where a "crash" comes into it.
read the original post: the game stops when the eu changes levels without
allowing the eu to a) save b) quit or c) die. If none of those three are
available before exit then it is by definition a crash however clean it may
look.

 

[Guest]

Archived from groups: rec.games.roguelike.nethack (More info?)

Dylan O'Donnell wrote:
> Klaus Kassner <Klaus.Kassner@physik.uni-magdeburg.de> writes:
>
>>Dylan O'Donnell wrote:
>>
>>
>>>This is so you can debug just how unviable the level is It wouldn't
>>>be suitable for normal play.
>>
>>I did not notice anything unusual on the "unviable" level. No
>>debugging was needed. Mind you, I don't think that real tampering
>>with the level files should be possible, so the trickery mechanism
>>should work as it does if something like that happens. However, what
>>we see here is a bug happening in the interaction of the game and some
>>operating system(s) (i.e. XP but probably not Linux).
>
>
> How should the game distinguish between the two cases?

Does the game not know, which one is the "unviable" level? If it is the
level your character is on or is about to change to, you can have the
game crash the normal way and recover should give a working game
afterwards. If it is a level far from the one on which the character
is, have a trickery happen as now.
--
Klaus Kassner

 

[Guest]

Archived from groups: rec.games.roguelike.nethack (More info?)

chuck wrote:
Oh chuck, I can't possibly express in words how much I love debating
with you.

> Sebastian Hungerecker <sepp00@web.de> wrote in news:d3amv3$iid$01$1@news.t-
> online.com:
>>No, trickery is if the game thinks the player cheats. Then it will end
>>itself and note in the score file, that the player died by trickery.
>>This is not a real crash.
>
> I suggest you re-read the OP.

|X| Done.


> The poster specifically says that the game
> stopped when he changed levels with some message about levels not matching.

Yes, he does.


> THAT is a crash The game did not exit cleanly which would be one of three
> possiblities 1) saving 2) dieing

The game thought he cheated, so it killed him. It's not a real crash -
he had the chance to identify his posession and he got an entry in the
score file.


> or the short answer: if you have to
> recover that is a crash.

Yes, but in case of trickery recovering doesn't work because the game
didn't technically crash.


>>The OP died by trickery (that's why this thread's subject line is
>>"tricked") and so did xyblor.
>
> see above. Or better yet read my last message again, you aren't understanding
> it.

You aren't understanding. The game thought he cheated -> it killed him
-> it did everything it does when a player dies (dywypi etc.) -> it made
an entry in the scorefile and noted "trickery" as the cause of death

--
If geiger counter does not click,
the coffee, she is just not thick

 

[Guest]

Archived from groups: rec.games.roguelike.nethack (More info?)

chuck <chucko@nil.car> wrote:

> "Paul Dunn" <paul.dunn4@ntlworld.com> wrote in
> news:iV96e.3602$C2.192@newsfe3-win.ntli.net:
>
> > Having read both posts I would consider neither to be a crash, but both had
> > their games ended by trickery. He said that he's had a few games "ended" by
> > trickery, and he was replying to a thread about games ending in trickery. I
> > don't see where a "crash" comes into it.
> read the original post: the game stops when the eu changes levels

That'll be when the new constitution is adopted, then?

> without allowing the eu to a) save b) quit or c) die. If none of those three are
> available before exit then it is by definition a crash however clean it may
> look.

*Bzzt* Wrong, but thank you for playing.

As any programmer knows, a crash is an _uncontrolled_ abnormal
termination of the program (or, just as inapplicably, an uncontrolled
non-termination of same). EOG due to trickery is perfectly controlled,
by the game at least.

Richard

 

[Chuck]

Archived from groups: rec.games.roguelike.nethack (More info?)

Sebastian Hungerecker <sepp00@web.de> wrote in news:d3e6k6$mg1$00$1@news.t-
online.com:

> chuck wrote:
> Oh chuck, I can't possibly express in words how much I love debating
> with you.
> You aren't understanding. The game thought he cheated -> it killed him
> -> it did everything it does when a player dies (dywypi etc.) -> it made
> an entry in the scorefile and noted "trickery" as the cause of death
Yess I realize all that, but the point was as I said and another poster said
in another way; If the level is not properly saved at all (by either write-
behind caching or lack of disk space) you will get the same effect BTW write
behind caching is enabled by default in Windows.

 

[Chuck]

Archived from groups: rec.games.roguelike.nethack (More info?)

>
> *Bzzt* Wrong, but thank you for playing.
>
> As any programmer knows, a crash is an _uncontrolled_ abnormal
> termination of the program (or, just as inapplicably, an uncontrolled
> non-termination of same). EOG due to trickery is perfectly controlled,
> by the game at least.
>
If I were to take your point as being vaild (which I don't due to such things
as exception handling from interupts) it is not germane to the issus at hand
which is whether the eu changed files or caching/lack of disk space caused
the problem one of which is trickery the other is a crash.

 

[Guest]

Archived from groups: rec.games.roguelike.nethack (More info?)

On Mon, 11 Apr 2005, Richard Bos wrote:
> chuck <chucko@nil.car> wrote:
>> without allowing the eu to a) save b) quit or c) die. If none of those three are
>> available before exit then it is by definition a crash however clean it may
>> look.
>
> *Bzzt* Wrong, but thank you for playing.
>
> As any programmer knows, a crash is an _uncontrolled_ abnormal
> termination of the program (or, just as inapplicably, an uncontrolled
> non-termination of same). EOG due to trickery is perfectly controlled,
> by the game at least.

I would disagree. A death to the trickery is the controlled way of
handling an uncontrolled error condition.

Just like coughing up and throwing a blue screen is much nicer than just
locking up.

My definition of a crash is: "a major failure of a program that causes an
unrecoverable loss of whatever the program was doing". It's something
that forces you to start anew. Having a pretty animation displayed as the
program in question goes down doesn't change anything -- for example,
under Unix, all you need is signal(SIGSEGV, death_animation).

KiloByte, killed by a segmentation fault

,-=========================================-. Rule #35: That which
| 1KB | does not kill you has
`-------------------------------------------' made a tactical error.
- The Seven Habits of Highly Effective Pirates

 

[Chuck]

Archived from groups: rec.games.roguelike.nethack (More info?)

Adam Borowski <kilobyte@mimuw.edu.pl> wrote in
newsine.LNX.4.62.0504120016280.30069@angband.pl:

> On Mon, 11 Apr 2005, Richard Bos wrote:
>> chuck <chucko@nil.car> wrote:
>>> without allowing the eu to a) save b) quit or c) die. If none of those
three are
>>> available before exit then it is by definition a crash however clean it
may
>>> look.
>>
>> *Bzzt* Wrong, but thank you for playing.
>>
>> As any programmer knows, a crash is an _uncontrolled_ abnormal
>> termination of the program (or, just as inapplicably, an uncontrolled
>> non-termination of same). EOG due to trickery is perfectly controlled,
>> by the game at least.
>
> I would disagree. A death to the trickery is the controlled way of
> handling an uncontrolled error condition.
>
> Just like coughing up and throwing a blue screen is much nicer than just
> locking up.
>
> My definition of a crash is: "a major failure of a program that causes an
> unrecoverable loss of whatever the program was doing". It's something
> that forces you to start anew. Having a pretty animation displayed as the
> program in question goes down doesn't change anything -- for example,
> under Unix, all you need is signal(SIGSEGV, death_animation).

That matches my original point. If you have no disk space showing as free in
linux for example you get a message that says: cannot write lock... and an
immediate exit. This is not quiting dying or saving.

 

[Guest]

Archived from groups: rec.games.roguelike.nethack (More info?)

Sebastian Hungerecker wrote:

> Yes, but in case of trickery recovering doesn't work because the game
> didn't technically crash.

True, but the whole point of discussing this trickery issue at all is
that while the game does not technically crash, this is wrong in cases
where the player doesn't try to cheat. It is a bug that the game lets
the player die by trickery, when he did not attempt any. What the game
*should* do in that case is to produce an honest crash, with the
possibility of using recovery.

 

[Guest]

Archived from groups: rec.games.roguelike.nethack (More info?)

On 4/12/05 4:23 AM, Klaus Kassner wrote:
> Sebastian Hungerecker wrote:
>
>
>>Yes, but in case of trickery recovering doesn't work because the game
>>didn't technically crash.
>
>
> True, but the whole point of discussing this trickery issue at all is
> that while the game does not technically crash, this is wrong in cases
> where the player doesn't try to cheat. It is a bug that the game lets
> the player die by trickery, when he did not attempt any. What the game
> *should* do in that case is to produce an honest crash, with the
> possibility of using recovery.

Wouldn't work. The recovery utility only works for those situations
where you are trying to start a game and don't have a savefile but
rather all the level files you would normally have in an open game.
These files all have to be uncorrupted, though, or the recovery won't
work. In a "trickery" situation, the game has already ascertained that a
level file is corrupt.

--
Kevin Wayne

"I came to Casablanca for the waters."
"Waters? What waters? We're in the desert?"
"I was misinformed."

 

[Guest]

Archived from groups: rec.games.roguelike.nethack (More info?)

Klaus Kassner <Klaus.Kassner@physik.uni-magdeburg.de> wrote:

> Sebastian Hungerecker wrote:
>
> > Yes, but in case of trickery recovering doesn't work because the game
> > didn't technically crash.
>
> True, but the whole point of discussing this trickery issue at all is
> that while the game does not technically crash, this is wrong in cases
> where the player doesn't try to cheat. It is a bug that the game lets
> the player die by trickery, when he did not attempt any. What the game
> *should* do in that case is to produce an honest crash, with the
> possibility of using recovery.

Even disregarding the impossibility of recovery when a level file is
corrupted, how do you propose that the game distinguish between "level
file is corrupt because the user tried to cheat" and "level file is
corrupt because of a bug in the game|the OS|the hard drive"?

Richard

 

[Guest]

Archived from groups: rec.games.roguelike.nethack (More info?)

Adam Borowski <kilobyte@mimuw.edu.pl> wrote:

> On Mon, 11 Apr 2005, Richard Bos wrote:
> > chuck <chucko@nil.car> wrote:
> >> without allowing the eu to a) save b) quit or c) die. If none of those three are
> >> available before exit then it is by definition a crash however clean it may
> >> look.
> >
> > *Bzzt* Wrong, but thank you for playing.
> >
> > As any programmer knows, a crash is an _uncontrolled_ abnormal
> > termination of the program (or, just as inapplicably, an uncontrolled
> > non-termination of same). EOG due to trickery is perfectly controlled,
> > by the game at least.
>
> I would disagree. A death to the trickery is the controlled way of
> handling an uncontrolled error condition.

Even so, the death _itself_ is controlled. It's an abnormal abort, not a
crash.

> Just like coughing up and throwing a blue screen is much nicer than just
> locking up.

IME, there isn't much difference between the two :-/ In fact, the BSOD
is frequently worse, since it locks up the entire system rather than
just the offending program.

> My definition of a crash is: "a major failure of a program that causes an
> unrecoverable loss of whatever the program was doing".

That would include situations where the program continues to run, but
closes one of its documents, then?

Richard

 

[Guest]

Archived from groups: rec.games.roguelike.nethack (More info?)

Kevin Wayne wrote:
> On 4/12/05 4:23 AM, Klaus Kassner wrote:
>
>> Sebastian Hungerecker wrote:
>>
>>
>>> Yes, but in case of trickery recovering doesn't work because the game
>>> didn't technically crash.
>>
>>
>>
>> True, but the whole point of discussing this trickery issue at all is
>> that while the game does not technically crash, this is wrong in cases
>> where the player doesn't try to cheat. It is a bug that the game lets
>> the player die by trickery, when he did not attempt any. What the
>> game *should* do in that case is to produce an honest crash, with the
>> possibility of using recovery.
>
>
> Wouldn't work. The recovery utility only works for those situations
> where you are trying to start a game and don't have a savefile but
> rather all the level files you would normally have in an open game.
> These files all have to be uncorrupted, though, or the recovery won't
> work. In a "trickery" situation, the game has already ascertained that a
> level file is corrupt.

It seems obvious to me that it has not in all cases done that. In the
cases where it happened to me, none of the level files had been tampered
with, and the message was just: "Could not create file...", with the
name of an old level file. This means that recover would work, if only
the file that was still on disk would be taken instead of the one that
the game attempted to create futilely.

Second, it is not true that recover does not work with games where not
all the level files are present. I had exactly this situation. One
level file had gotten lost. Recover worked fine, I could restart the
game. But I knew that something was wrong, as I had seen on the
playground, that level file no. 1 was missing (the game had frozen, and
my only way to get out of it was to kill the window). When I tried to
save the recovered game, it crashed irrecoverably.

Now this suggests to use this obvious flexibility of the recover program
to do allow recovery in all cases, where the game believes to see a
trickery, but to display the trickery message to warn the player. In
the cases, where the game was wrong, because it detected a trickery due
to its bug, the file structure would be o.k. as the player could
determine by immediately resaving the game after recovery. In the case
where there was a true trickery (a much rarer situation, I would
suppose), recover would work, too, but the game would be lost on the
attempt to save it after a restart. That would be a decent way to have
the distinction between true attempts to cheat and only apparent ones.
--
Klaus Kassner

 

[Guest]

Archived from groups: rec.games.roguelike.nethack (More info?)

Richard Bos wrote:
> Klaus Kassner <Klaus.Kassner@physik.uni-magdeburg.de> wrote:
>
>
>>Sebastian Hungerecker wrote:
>>
>>
>>>Yes, but in case of trickery recovering doesn't work because the game
>>>didn't technically crash.
>>
>>True, but the whole point of discussing this trickery issue at all is
>>that while the game does not technically crash, this is wrong in cases
>>where the player doesn't try to cheat. It is a bug that the game lets
>>the player die by trickery, when he did not attempt any. What the game
>>*should* do in that case is to produce an honest crash, with the
>>possibility of using recovery.
>
>
> Even disregarding the impossibility of recovery when a level file is

Which is not given, see my answer to Kevin Wayne.

> corrupted, how do you propose that the game distinguish between "level
> file is corrupt because the user tried to cheat" and "level file is
> corrupt because of a bug in the game|the OS|the hard drive"?

I answered that before in a post replying to Dylan O'Donnel. In the
latter case, it is the last level the player changed to or came from
that would be important, in the former, it can be any level. I think it
is more or less clear why the thing happens. When you return to a level
too fast, the latest version that the game remembers has not yet been
(completely) written to disk (for whatever OS-related reasons) and so
the game believes the older version that it still finds there is one
that has been tampered with.

 

[Guest]

Archived from groups: rec.games.roguelike.nethack (More info?)

Ken Cuvelier wrote:
> xyblor wrote:
>
>>sluissa@gmail.com wrote:
>>
>>>[death by trickery on winxp is annoying]
>>
>>I play 3.4.3 on windows XP and about a third of my games end in
>>trickery. I'd like to know how many other people have this problem, and
>>whether or not it has been acknowledged by the devteam. Does anyone have
>>any suggestions as to how to fix it?
>>
>>The following circumstances don't fix my problem:
>>- reinstalling from various different mirrors
>>- having >3 GB of free space on all hard drives
>>- setting "turn off hard drives after:" to "never" in control panel ->
>>power options
>>- using the ascii interface instead of the windows one
>
> [try disabling write caching]

Well I just had my first death by trickery after disabling write
caching, so I guess we can add that to the list of solutions that don't
work.

Thanks anyway for the idea, Ken!

 

[Guest]

Archived from groups: rec.games.roguelike.nethack (More info?)

xyblor wrote:
> Well I just had my first death by trickery after disabling write
> caching, so I guess we can add that to the list of solutions that don't
> work.
>
> Thanks anyway for the idea, Ken!

Bummer. The upside is that your filesystem may be a little bit less
vulnerable to damage with write caching disabled. Just another question
for you to see what's what: are you using a dual-processor system? If
not, is it a P4 with hyperthreading? I've heard of strangeness with
file accesses in other programs running on multiprocessor systems with
Windows XP.

-Ken

 

[Guest]

Archived from groups: rec.games.roguelike.nethack (More info?)

Ken Cuvelier wrote:
> xyblor wrote:
>
>>Well I just had my first death by trickery after disabling write
>>caching, so I guess we can add that to the list of solutions that don't
>>work.
>
> Bummer. The upside is that your filesystem may be a little bit less
> vulnerable to damage with write caching disabled. Just another question
> for you to see what's what: are you using a dual-processor system? If
> not, is it a P4 with hyperthreading? I've heard of strangeness with
> file accesses in other programs running on multiprocessor systems with
> Windows XP.

No, I just have a single processor Athlon XP 2400. It is underclocked a
little bit. I've had this system for a year, with no other file
read/write problems.