Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.mac.system > #56663 > unrolled thread

Can't Eject a Volume

Back to article view | Back to comp.sys.mac.system

Contents

  Can't Eject a Volume nicknaym@_remove_this_gmail.com.invalid (Nick Naym) - 2014-02-18 14:32 -0500
    Re: Can't Eject a Volume nospam <nospam@nospam.invalid> - 2014-02-18 14:48 -0500
    Re: Can't Eject a Volume billy@MIX.COM - 2014-02-18 19:52 +0000
      Re: Can't Eject a Volume Alan Baker <alangbaker@telus.net> - 2014-02-22 12:05 -0800
        Re: Can't Eject a Volume Jolly Roger <jollyroger@pobox.com> - 2014-02-22 21:25 +0000
          Re: Can't Eject a Volume Alan Baker <alangbaker@telus.net> - 2014-02-22 21:03 -0800
    Re: Can't Eject a Volume Jolly Roger <jollyroger@pobox.com> - 2014-02-18 20:13 +0000
    Re: Can't Eject a Volume Alan Ralph <alan.ralph@gmail.com> - 2014-02-18 20:18 +0000
      Re: Can't Eject a Volume Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-02-20 15:13 +0000
        Re: Can't Eject a Volume Alan Ralph <alan.ralph@gmail.com> - 2014-02-20 21:07 +0000
          Re: Can't Eject a Volume Jolly Roger <jollyroger@pobox.com> - 2014-02-20 21:52 +0000
            Re: Can't Eject a Volume nospam <nospam@nospam.invalid> - 2014-02-21 06:27 -0500
              Re: Can't Eject a Volume Jolly Roger <jollyroger@pobox.com> - 2014-02-21 16:53 +0000
                Re: Can't Eject a Volume nospam <nospam@nospam.invalid> - 2014-02-21 13:07 -0500
                  Re: Can't Eject a Volume Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-22 12:38 -0500
                    Re: Can't Eject a Volume Jolly Roger <jollyroger@pobox.com> - 2014-02-22 21:24 +0000
                Re: Can't Eject a Volume Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-02-21 22:51 +0000
          Re: Can't Eject a Volume Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-02-21 01:35 +0000
            Re: Can't Eject a Volume nospam <nospam@nospam.invalid> - 2014-02-21 06:27 -0500
            Re: Can't Eject a Volume Jolly Roger <jollyroger@pobox.com> - 2014-02-21 17:02 +0000
              Re: Can't Eject a Volume Tim Streater <timstreater@greenbee.net> - 2014-02-21 17:10 +0000
                Re: Can't Eject a Volume Jolly Roger <jollyroger@pobox.com> - 2014-02-21 17:21 +0000
                Re: Can't Eject a Volume nospam <nospam@nospam.invalid> - 2014-02-21 13:07 -0500
              Re: Can't Eject a Volume nospam <nospam@nospam.invalid> - 2014-02-21 13:07 -0500
                Re: Can't Eject a Volume Jolly Roger <jollyroger@pobox.com> - 2014-02-21 19:14 +0000
                  Re: Can't Eject a Volume nospam <nospam@nospam.invalid> - 2014-02-21 14:49 -0500
                    Re: Can't Eject a Volume Jolly Roger <jollyroger@pobox.com> - 2014-02-21 22:13 +0000
                      Re: Can't Eject a Volume nospam <nospam@nospam.invalid> - 2014-02-22 00:29 -0500
                        Re: Can't Eject a Volume Jolly Roger <jollyroger@pobox.com> - 2014-02-22 16:59 +0000
                        Re: Can't Eject a Volume Barry OGrady <atheist@hotmail.com.au> - 2014-02-25 16:49 +1100
                Re: Can't Eject a Volume Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-21 18:28 -0500
                  Re: Can't Eject a Volume nospam <nospam@nospam.invalid> - 2014-02-22 00:29 -0500
                    Re: Can't Eject a Volume Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-22 10:02 -0500
                      Re: Can't Eject a Volume Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-22 10:22 -0500
                        Re: Can't Eject a Volume Jolly Roger <jollyroger@pobox.com> - 2014-02-22 17:01 +0000
                          Re: Can't Eject a Volume Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-22 12:13 -0500
                            Re: Can't Eject a Volume Jolly Roger <jollyroger@pobox.com> - 2014-02-22 17:16 +0000
                              Re: Can't Eject a Volume Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-02-22 12:34 -0500
                                Re: Can't Eject a Volume Jolly Roger <jollyroger@pobox.com> - 2014-02-22 21:23 +0000
                                Re: Can't Eject a Volume Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-02-22 21:46 +0000
                                  Re: Can't Eject a Volume Jolly Roger <jollyroger@pobox.com> - 2014-02-22 21:53 +0000
                      Re: Can't Eject a Volume Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-02-22 17:00 +0000
    Re: Can't Eject a Volume M-M <nospam.m-m@ny.more> - 2014-02-18 20:37 -0500
      Re: Can't Eject a Volume Jolly Roger <jollyroger@pobox.com> - 2014-02-19 02:13 +0000
        Re: Can't Eject a Volume nospam <nospam@nospam.invalid> - 2014-02-18 21:42 -0500
          Re: Can't Eject a Volume Jolly Roger <jollyroger@pobox.com> - 2014-02-19 04:21 +0000
            Re: Can't Eject a Volume nospam <nospam@nospam.invalid> - 2014-02-18 23:35 -0500
    Re: Can't Eject a Volume Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-02-20 15:13 +0000

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#56800

In article <bmpf4dF1uueU2@mid.individual.net>, Jolly Roger
<jollyroger@pobox.com> wrote:

> On 2014-02-21, Lewis <g.kreme@gmail.com.dontsendmecopies> wrote:
> > In message <le5qqs$n2q$1@dont-email.me> Alan Ralph
> > <alan.ralph@gmail.com> wrote:
> >> On 20/02/2014 15:13, Lewis wrote:
> >>> In message <le0f64$i8t$1@dont-email.me> Alan Ralph
> >>> <alan.ralph@gmail.com> wrote:
> >>>>
> >>>> It may well be Finder itself still accessing the external disk. Select
> >>>> 'Force Quit' from the Apple menu, select Finder, click 'Relaunch', then
> >>>> wait while Finder restarts and refreshes the desktop. This also works
> >>>> for CDs or DVDs that refuse to eject.
> >>>
> >>> Don't do this.
> >
> >> Care to expand on why you think it's the wrong course of action?
> >
> > Force quitting apps is generally to be avoided.
> 
> To expand on this, force quitting an application can cause any file that
> the application currently has open to become corrupt, since it does not
> give the application a chance to finish updating the file in question
> and close it before quitting. Applications may have their own preference
> files open, or other files on your startup volume. If an application's
> preference file becomes malformed or corrupt, it can cause the
> application in question to behave in unpredictable ways on subsequent
> launches.

The files will all be closed when the app quits. You *might* leave an
important file in a dicky state, but not necessarily. I force-quit Word
2008 quit often, but it starts up just fine every time.

> > Force quitting an app like the Finder where you are never sure of the
> > state it is in is absolutely to be avoided.
> 
> I'm not sure I would consider Finder to be that fragile - certainly not
> as fragile as other applications or system processes. If there is a file
> copy in progress, you certainly ant to avoid force quitting it, and as
> stated above, there is always the possibility that you can cause Finder
> preference files to become corrupt if you force quit it. But in general,
> if your system is relatively idle, you can often force quit the Finder
> without too much concern.

Well quite. And if that's still a concern, get hold of one of the many
apps that will add a Quit item to Finder.

In fact looking at the Force-Quit window, if you choose Finder the
button changes to say "Relaunch", so that would seem safe enough.

-- 
"People don't buy Microsoft for quality, they buy it for compatibility
with what Bob in accounting bought last year. Trace it back - they buy
Microsoft because the IBM Selectric didn't suck much" - P Seebach, afc

[toc] | [prev] | [next] | [standalone]

#56802

On 2014-02-21, Tim Streater <timstreater@greenbee.net> wrote:
> In article <bmpf4dF1uueU2@mid.individual.net>, Jolly Roger
><jollyroger@pobox.com> wrote:
>
>> On 2014-02-21, Lewis <g.kreme@gmail.com.dontsendmecopies> wrote:
>>>
>>> Force quitting apps is generally to be avoided.
>> 
>> To expand on this, force quitting an application can cause any file that
>> the application currently has open to become corrupt, since it does not
>> give the application a chance to finish updating the file in question
>> and close it before quitting. Applications may have their own preference
>> files open, or other files on your startup volume. If an application's
>> preference file becomes malformed or corrupt, it can cause the
>> application in question to behave in unpredictable ways on subsequent
>> launches.
>
> The files will all be closed when the app quits.

Not always, no. I've seen applications leave files in an open state
after a force quit.

> You *might* leave an
> important file in a dicky state, but not necessarily.

How does that contradict anything I said above?

> I force-quit Word 2008 quit often, but it starts up just fine every
> time.

Good for you. Nothing you have said contradicts anything above.

-- 
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR

[toc] | [prev] | [next] | [standalone]

#56805

In article <210220141710070112%timstreater@greenbee.net>, Tim Streater
<timstreater@greenbee.net> wrote:

> In fact looking at the Force-Quit window, if you choose Finder the
> button changes to say "Relaunch", so that would seem safe enough.

yep.

[toc] | [prev] | [next] | [standalone]

#56804

In article <bmpf4dF1uueU2@mid.individual.net>, Jolly Roger
<jollyroger@pobox.com> wrote:

> To expand on this, force quitting an application can cause any file that
> the application currently has open to become corrupt, since it does not
> give the application a chance to finish updating the file in question
> and close it before quitting. Applications may have their own preference
> files open, or other files on your startup volume. If an application's
> preference file becomes malformed or corrupt, it can cause the
> application in question to behave in unpredictable ways on subsequent
> launches.

that's possible, but very unlikely because files are written atomically.

you might lose changes you made since the last save, but that's about
it. it's extremely unlikely that anything will be corrupted.

however, nothing is perfect and there is a very tiny chance something
could go wrong. files can get corrupted even without force-quitting.
shit happens.

> > Force quitting an app like the Finder where you are never sure of the
> > state it is in is absolutely to be avoided.
> 
> I'm not sure I would consider Finder to be that fragile - certainly not
> as fragile as other applications or system processes.

nonsense. finder is one of the buggiest parts of os x and apple has
shown no interest in fixing it.

some of its bugs have been there for years, as far back as os x 10.0.
it still gets file/folder sizes wrong and does not properly handle time
zones. apparently, nobody at apple ever leaves cupertino. if someone
cancels emptying trash, it will usually get stuck canceling, and the
only way to fix that is force-quit. the list goes on.

[toc] | [prev] | [next] | [standalone]

#56808

On 2014-02-21, nospam <nospam@nospam.invalid> wrote:
> In article <bmpf4dF1uueU2@mid.individual.net>, Jolly Roger
><jollyroger@pobox.com> wrote:
>
>> To expand on this, force quitting an application can cause any file that
>> the application currently has open to become corrupt, since it does not
>> give the application a chance to finish updating the file in question
>> and close it before quitting. Applications may have their own preference
>> files open, or other files on your startup volume. If an application's
>> preference file becomes malformed or corrupt, it can cause the
>> application in question to behave in unpredictable ways on subsequent
>> launches.
>
> that's possible, but very unlikely because files are written atomically.

mr.know-it-all won't be able to provide evidence that all (or even most)
files are written atomically by all applications. The fact is that
application developers may choose keep files open for relatively long
periods of time, and whether an application has a file open, or has
completed writing to that file, at any point in time cannot be predicted
ahead of time.

Now I predict mr.know-it-all will try to move the goal posts, which is
typical of his silly tit-for-tat arguments...

>> > Force quitting an app like the Finder where you are never sure of the
>> > state it is in is absolutely to be avoided.
>> 
>> I'm not sure I would consider Finder to be that fragile - certainly not
>> as fragile as other applications or system processes.
>
> nonsense. finder is one of the buggiest parts of os x and apple has
> shown no interest in fixing it.

Now he's trying to move the goal posts yet again. He ignores that we are
talking specifically about files open by the Finder. Now he's trying to
change the topic to general Finder bugs. Lame. That's not what we are
discussing here. Nice try, but no cigar, mr.know-it-all.

-- 
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR

[toc] | [prev] | [next] | [standalone]

#56810

In article <bmpmthF3of8U1@mid.individual.net>, Jolly Roger
<jollyroger@pobox.com> wrote:

> >> To expand on this, force quitting an application can cause any file that
> >> the application currently has open to become corrupt, since it does not
> >> give the application a chance to finish updating the file in question
> >> and close it before quitting. Applications may have their own preference
> >> files open, or other files on your startup volume. If an application's
> >> preference file becomes malformed or corrupt, it can cause the
> >> application in question to behave in unpredictable ways on subsequent
> >> launches.
> >
> > that's possible, but very unlikely because files are written atomically.
> 
> mr.know-it-all won't be able to provide evidence that all (or even most)
> files are written atomically by all applications. The fact is that
> application developers may choose keep files open for relatively long
> periods of time, and whether an application has a file open, or has
> completed writing to that file, at any point in time cannot be predicted
> ahead of time.

developers could do a lot of things. that doesn't mean they do.

the vast majority of developers are not stupid and write files
atomically because they know that's the safest way to do it. 

not only that, but just because a file is open when an app is
force-quit does mean it will be corrupted. a force-quit is typically
done *after* an app has crashed, so the damage, if any, has already
happened. 

if this was a huge problem, we'd be hearing about data loss when people
force-quit apps, and we don't, therefore it's not a serious issue.

real world experience is what matters.

> Now I predict mr.know-it-all will try to move the goal posts, which is
> typical of his silly tit-for-tat arguments...

i'm not the one who is moving the goalposts. 

> >> > Force quitting an app like the Finder where you are never sure of the
> >> > state it is in is absolutely to be avoided.
> >> 
> >> I'm not sure I would consider Finder to be that fragile - certainly not
> >> as fragile as other applications or system processes.
> >
> > nonsense. finder is one of the buggiest parts of os x and apple has
> > shown no interest in fixing it.
> 
> Now he's trying to move the goal posts yet again. He ignores that we are
> talking specifically about files open by the Finder. Now he's trying to
> change the topic to general Finder bugs. Lame. That's not what we are
> discussing here. Nice try, but no cigar, mr.know-it-all.

actually it is what is being discussed. 

or have you already forgotten that *you* said finder was not fragile? 

typical for you, when facts are shoved in your face, you get all bent
out of shape.

[toc] | [prev] | [next] | [standalone]

#56814

On 2014-02-21, nospam <nospam@nospam.invalid> wrote:
> In article <bmpmthF3of8U1@mid.individual.net>, Jolly Roger
><jollyroger@pobox.com> wrote:
>
>> >> To expand on this, force quitting an application can cause any file that
>> >> the application currently has open to become corrupt, since it does not
>> >> give the application a chance to finish updating the file in question
>> >> and close it before quitting. Applications may have their own preference
>> >> files open, or other files on your startup volume. If an application's
>> >> preference file becomes malformed or corrupt, it can cause the
>> >> application in question to behave in unpredictable ways on subsequent
>> >> launches.
>> >
>> > that's possible, but very unlikely because files are written atomically.
>> 
>> mr.know-it-all won't be able to provide evidence that all (or even most)
>> files are written atomically by all applications. The fact is that
>> application developers may choose keep files open for relatively long
>> periods of time, and whether an application has a file open, or has
>> completed writing to that file, at any point in time cannot be predicted
>> ahead of time.
>
> developers could do a lot of things. that doesn't mean they do.
>
> the vast majority of developers are not stupid and write files
> atomically because they know that's the safest way to do it. 

Just as I predicted, mr.know-it-all can't produce a shred of proof of
his asinine assertion. No surprise. As an actual professional software
developer, I have seen with my own eyes quite a large number of both
lazy and even well-meaning developers fail to follow best practices a
large portion of the time. I've even observed this in code written by
Apple developers. I've also seen with my own eyes application preference
files becoming malformed due to force quitting in the past. So it's only
natural that I question mr.know-it-all's silly assertion that file
corruption due to force quitting applications is very unlikely. Notice
how he still is unable to offer proof of his assertion. I'm still
waiting, but I won't wait forever.

> not only that, but just because a file is open when an app is
> force-quit does mean it will be corrupted. a force-quit is typically
> done *after* an app has crashed, so the damage, if any, has already
> happened. 

Now mr.know-it-all is trying to move the goal posts, and suggesting that
typically force quitting is only done after applications have crashed,
(which is rather silly, considering an application that has crashed
*can't* be quit because it's no longer running - the very definition of
a crash). Ludicrous! But he'll keep digging the hole deeper, because he
simply cannot admit he is wrong - ever. He would love us to ignore that
he hasn't yet produced a single shred of proof of his original assertion
by distracting us with yet another hair-brained assertion. He's a silly
weasel, that's for sure!

> if this was a huge problem, we'd be hearing about data loss when people
> force-quit apps, and we don't, therefore it's not a serious issue.

Straw man. Nobody in this thread suggested there was a huge problem.
Nice try, weasel. Keep digging!

> real world experience is what matters.

As a professional software developer, I have enough real-world
experience to say with confidence that applications can and do keep
files open while running, and force quitting those applications can
result in malformed or incomplete data in said filed. Anyone disputing
this clearly doesn't know much about the reality of software
development. But mr.know-it-all thinks he knows better than every other
human being on planet Earth. And he'll continue to argue about this
until we get bored with his shenanigans. Then he'll take our lack of
participation in his petty argument as a sign that he has somehow won
the argument. Sad.

>> Now I predict mr.know-it-all will try to move the goal posts, which is
>> typical of his silly tit-for-tat arguments...
>
> i'm not the one who is moving the goalposts. 
>
>> >> > Force quitting an app like the Finder where you are never sure of the
>> >> > state it is in is absolutely to be avoided.
>> >> 
>> >> I'm not sure I would consider Finder to be that fragile - certainly not
>> >> as fragile as other applications or system processes.
>> >
>> > nonsense. finder is one of the buggiest parts of os x and apple has
>> > shown no interest in fixing it.
>> 
>> Now he's trying to move the goal posts yet again. He ignores that we are
>> talking specifically about files open by the Finder. Now he's trying to
>> change the topic to general Finder bugs. Lame. That's not what we are
>> discussing here. Nice try, but no cigar, mr.know-it-all.
>
> actually it is what is being discussed. 
>
> or have you already forgotten that *you* said finder was not fragile? 
>
> typical for you, when facts are shoved in your face, you get all bent
> out of shape.

DING DING DING! Straw man again! mr.know-it-all bullheadedly continues
insisting that we were talking about Finder bugs in general when it's
clear as day that my statement, in context with the entirety of this
thread, is about force quitting Finder and resulting file
malformation/corruption. He has to do this, because he knows he has no
valid argument about the topic at hand.  So he tries to change the topic
of discussion. Lame. Keep digging, you silly weasel boy!

-- 
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR

[toc] | [prev] | [next] | [standalone]

#56820

In article <bmq1cmF5p5pU2@mid.individual.net>, Jolly Roger
<jollyroger@pobox.com> wrote:

> >> >> To expand on this, force quitting an application can cause any file that
> >> >> the application currently has open to become corrupt, since it does not
> >> >> give the application a chance to finish updating the file in question
> >> >> and close it before quitting. Applications may have their own preference
> >> >> files open, or other files on your startup volume. If an application's
> >> >> preference file becomes malformed or corrupt, it can cause the
> >> >> application in question to behave in unpredictable ways on subsequent
> >> >> launches.
> >> >
> >> > that's possible, but very unlikely because files are written atomically.
> >> 
> >> mr.know-it-all won't be able to provide evidence that all (or even most)
> >> files are written atomically by all applications. The fact is that
> >> application developers may choose keep files open for relatively long
> >> periods of time, and whether an application has a file open, or has
> >> completed writing to that file, at any point in time cannot be predicted
> >> ahead of time.
> >
> > developers could do a lot of things. that doesn't mean they do.
> >
> > the vast majority of developers are not stupid and write files
> > atomically because they know that's the safest way to do it. 
> 
> Just as I predicted, mr.know-it-all can't produce a shred of proof of
> his asinine assertion.

where's you proof that app developers write files nonatomically? 

have you disassembled all of the millions of apps out there? (no)

or are you talking out your ass, as usual? (yes)

> No surprise. As an actual professional software
> developer, I have seen with my own eyes quite a large number of both
> lazy and even well-meaning developers fail to follow best practices a
> large portion of the time.

you're not the only software developer in this world and just because
you say something does not make it fact nor is it any sort of proof.

the reality is that it's not anywhere near the disaster you claim it to
be. 

although it's technically possible that it could happen, actual real
world experience indicates that it's rare. 

easy to test - force quit and see if anything is corrupted. repeat a
bunch of times. 

> I've even observed this in code written by
> Apple developers.

so what? i know a lot of apple engineers and have worked with many of
them at one point or another.

> I've also seen with my own eyes application preference
> files becoming malformed due to force quitting in the past. So it's only
> natural that I question mr.know-it-all's silly assertion that file
> corruption due to force quitting applications is very unlikely. Notice
> how he still is unable to offer proof of his assertion. I'm still
> waiting, but I won't wait forever.

notice that *you* haven't offered *any* proof at all. 

nobody said it won't ever happen. you are as usual, moving the
goalposts.

> > not only that, but just because a file is open when an app is
> > force-quit does mean it will be corrupted. a force-quit is typically
> > done *after* an app has crashed, so the damage, if any, has already
> > happened. 
> 
> Now mr.know-it-all is trying to move the goal posts, and suggesting that
> typically force quitting is only done after applications have crashed,
> (which is rather silly, considering an application that has crashed
> *can't* be quit because it's no longer running - the very definition of
> a crash). 

i'm not moving a thing.

apps can crash more than one way. sometimes they are terminated by the
system and sometimes they hang and need to be force-quit.

obviously, i'm referring to the latter. 

that's why there is an option to force-quit. if every crash was
automatically terminated, such an option would not be needed.

a 'professional developer' would have known that.

> Ludicrous! But he'll keep digging the hole deeper, because he
> simply cannot admit he is wrong - ever. He would love us to ignore that
> he hasn't yet produced a single shred of proof of his original assertion
> by distracting us with yet another hair-brained assertion. He's a silly
> weasel, that's for sure!

pot meet kettle.

you have yet to provide any proof. all you've said is it's true because
you said it's true. it doesn't work that way.

that makes you a lying hypocrite.

> > if this was a huge problem, we'd be hearing about data loss when people
> > force-quit apps, and we don't, therefore it's not a serious issue.
> 
> Straw man. Nobody in this thread suggested there was a huge problem.
> Nice try, weasel. Keep digging!

other than you, that is.

if we assume what you said above is true, where force-quitting an app
is almost certain to corrupt files, then it must be a huge problem.

you can't even keep your own story straight. 

> > real world experience is what matters.
> 
> As a professional software developer, I have enough real-world
> experience to say with confidence that applications can and do keep
> files open while running, and force quitting those applications can
> result in malformed or incomplete data in said filed. Anyone disputing
> this clearly doesn't know much about the reality of software
> development.

it *can* happen, but it doesn't happen all that often. in fact, it's
relatively rare.

real world experience always trumps theoretical possibilities. 

i force-quit finder a couple of times a month because it's a buggy
piece of shit and i haven't had any problems with corrupted files. i've
needed to do this since the early days of os x. 

xcode is much worse. on average, i need to force quit it several times
a day, and it keeps a *lot* of stuff open. not a single problem there
either.

i have seen xcode corrupt files *without* force-quitting, simply by
closing the project from the menus.

that means what you're saying is wrong. but you'll never admit it.

> But mr.know-it-all thinks he knows better than every other
> human being on planet Earth. And he'll continue to argue about this
> until we get bored with his shenanigans. Then he'll take our lack of
> participation in his petty argument as a sign that he has somehow won
> the argument. Sad.

more bullshit. none of that is true.

> >> >> > Force quitting an app like the Finder where you are never sure of the
> >> >> > state it is in is absolutely to be avoided.
> >> >> 
> >> >> I'm not sure I would consider Finder to be that fragile - certainly not
> >> >> as fragile as other applications or system processes.
> >> >
> >> > nonsense. finder is one of the buggiest parts of os x and apple has
> >> > shown no interest in fixing it.
> >> 
> >> Now he's trying to move the goal posts yet again. He ignores that we are
> >> talking specifically about files open by the Finder. Now he's trying to
> >> change the topic to general Finder bugs. Lame. That's not what we are
> >> discussing here. Nice try, but no cigar, mr.know-it-all.
> >
> > actually it is what is being discussed. 
> >
> > or have you already forgotten that *you* said finder was not fragile? 
> >
> > typical for you, when facts are shoved in your face, you get all bent
> > out of shape.
> 
> DING DING DING! Straw man again! mr.know-it-all bullheadedly continues
> insisting that we were talking about Finder bugs in general when it's
> clear as day that my statement, in context with the entirety of this
> thread, is about force quitting Finder and resulting file
> malformation/corruption.

you said finder is not fragile, without any facts to back up your claim.

the reality is that finder is very fragile. it's very buggy and apple
has zero interest in fixing it. some of the bugs have been there for
over 10 years and it's not particularly hard to make it crash either.
apple says 'works as designed'. interesting design goal, to crash. 

as i said above, i have to force-quit finder every so often and have
yet to lose *anything*, and that goes back to the early days of os x.

that's real world proof.

> He has to do this, because he knows he has no
> valid argument about the topic at hand.  So he tries to change the topic
> of discussion. Lame. Keep digging, you silly weasel boy!

i haven't changed anything. you are a liar.

[toc] | [prev] | [next] | [standalone]

#56826

On 2014-02-22, nospam <nospam@nospam.invalid> wrote:
> In article <bmq1cmF5p5pU2@mid.individual.net>, Jolly Roger
><jollyroger@pobox.com> wrote:
>
>> >> >> To expand on this, force quitting an application can cause any
>> >> >> file that the application currently has open to become corrupt,
>> >> >> since it does not give the application a chance to finish
>> >> >> updating the file in question and close it before quitting.
>> >> >> Applications may have their own preference files open, or other
>> >> >> files on your startup volume. If an application's preference
>> >> >> file becomes malformed or corrupt, it can cause the application
>> >> >> in question to behave in unpredictable ways on subsequent
>> >> >> launches.
>> >> >
>> >> > that's possible, but very unlikely because files are written
>> >> > atomically.
>> >> 
>> >> mr.know-it-all won't be able to provide evidence that all (or even
>> >> most) files are written atomically by all applications. The fact
>> >> is that application developers may choose keep files open for
>> >> relatively long periods of time, and whether an application has a
>> >> file open, or has completed writing to that file, at any point in
>> >> time cannot be predicted ahead of time.
>> >
>> > developers could do a lot of things. that doesn't mean they do.
>> >
>> > the vast majority of developers are not stupid and write files
>> > atomically because they know that's the safest way to do it. 
>> 
>> Just as I predicted, mr.know-it-all can't produce a shred of proof of
>> his asinine assertion.
>
> where's you proof that app developers write files nonatomically? 

Classic burden of proof fallacy. Now mr.know-it-all is attempting to
place the burden of poof on me, when it is *he* who cannot prove his
asinine assertion that all (or even most) files are written atomically
by all applications. Notice that he *still* hasn't been able to offer a
shred of proof of his assertion, yet continues to act as if I am wrong
for questioning his assertion. Nice, try, weasel boy, but you fail
again! He's a very foolish weasel!

>> No surprise. As an actual professional software developer, I have
>> seen with my own eyes quite a large number of both lazy and even
>> well-meaning developers fail to follow best practices a large portion
>> of the time.
>
> you're not the only software developer in this world and just because
> you say something does not make it fact nor is it any sort of proof.

Straw man again! I never said I was the only software developer in this
world, nor did I say anything was fact. All I did was ask for proof of
mr.know-it-all's silly assertion that all (or even most) files are
written atomically by all applications - something he simply cannot
prove.

> the reality is that it's not anywhere near the disaster you claim it
> to be. 

Straw man AGAIN! Nobody in this thread has suggested anythign is a
disaster, or anything close to it! You can't make this stuff up, kids.
Weasel boy just keep spinning the hits! Keep digging!

>> I've even observed this in code written by Apple developers.
>
> so what? i know a lot of apple engineers and have worked with many of
> them at one point or another.

The point you seem to be unable to get is that all software developers
make mistakes - even Apple software developers. That's all. You seem to
be unable or unwilling to accept this. So be it!

>> I've also seen with my own eyes application preference files becoming
>> malformed due to force quitting in the past. So it's only natural
>> that I question mr.know-it-all's silly assertion that file corruption
>> due to force quitting applications is very unlikely. Notice how he
>> still is unable to offer proof of his assertion. I'm still waiting,
>> but I won't wait forever.
>
> notice that *you* haven't offered *any* proof at all. 

Burden of proof fallacy again. I only questioned *your* assertion that
all (or even most) files are written atomically by all applications. The
burden of poof is on you, idiot! Keep digging, mr.weasel! That's a fine
hole you've got going!

>> > not only that, but just because a file is open when an app is
>> > force-quit does mean it will be corrupted. a force-quit is
>> > typically done *after* an app has crashed, so the damage, if any,
>> > has already happened. 
>> 
>> Now mr.know-it-all is trying to move the goal posts, and suggesting
>> that typically force quitting is only done after applications have
>> crashed, (which is rather silly, considering an application that has
>> crashed *can't* be quit because it's no longer running - the very
>> definition of a crash). 
>
> i'm not moving a thing.
>
> apps can crash more than one way. sometimes they are terminated by the
> system and sometimes they hang and need to be force-quit.

A hang isn't a crash. A crash isn't a hang. They are two distinctly
different states (something even novice software developers know), yet
you are trying to use them interchangeably. Nice try, but no cigar,
weasel boy. Keep digging!

>> Ludicrous! But he'll keep digging the hole deeper, because he simply
>> cannot admit he is wrong - ever. He would love us to ignore that he
>> hasn't yet produced a single shred of proof of his original assertion
>> by distracting us with yet another hair-brained assertion. He's a
>> silly weasel, that's for sure!
>
> pot meet kettle.
>
> you have yet to provide any proof. all you've said is it's true
> because you said it's true. it doesn't work that way.

Burden of proof fallacy yet again! Weasel boy makes assertions he can;t
back up, then tries to turn the tables asking others for proof he's not
right! He's a delusional sad little weasel!

> that makes you a lying hypocrite.

Ad hominem attack! The last resort of a silly little weasel!

>> > if this was a huge problem, we'd be hearing about data loss when
>> > people force-quit apps, and we don't, therefore it's not a serious
>> > issue.
>> 
>> Straw man. Nobody in this thread suggested there was a huge problem.
>> Nice try, weasel. Keep digging!
>
> other than you, that is.
>
> if we assume what you said above is true, where force-quitting an app
> is almost certain to corrupt files, then it must be a huge problem.

Except I never said that. Straw man again? Really, mr.weasel? This is
getting very boring! Please keep digging - eventually we won't be able
to hear you anymore!

>> > real world experience is what matters.
>> 
>> As a professional software developer, I have enough real-world
>> experience to say with confidence that applications can and do keep
>> files open while running, and force quitting those applications can
>> result in malformed or incomplete data in said filed. Anyone
>> disputing this clearly doesn't know much about the reality of
>> software development.
>
> it *can* happen, but it doesn't happen all that often. in fact, it's
> relatively rare.

Another bold claim! Please do provide proof of this new assertion! Oh,
right. You can't, and you'll attempt to turn the tables and ask me for
proof you aren't right. Got it. Boring.

>> But mr.know-it-all thinks he knows better than every other human
>> being on planet Earth. And he'll continue to argue about this until
>> we get bored with his shenanigans. Then he'll take our lack of
>> participation in his petty argument as a sign that he has somehow won
>> the argument. Sad.
>
> more bullshit. none of that is true.

Sure seems that way to me.

>> >> >> > Force quitting an app like the Finder where you are never
>> >> >> > sure of the state it is in is absolutely to be avoided.
>> >> >> 
>> >> >> I'm not sure I would consider Finder to be that fragile -
>> >> >> certainly not as fragile as other applications or system
>> >> >> processes.
>> >> >
>> >> > nonsense. finder is one of the buggiest parts of os x and apple
>> >> > has shown no interest in fixing it.
>> >> 
>> >> Now he's trying to move the goal posts yet again. He ignores that
>> >> we are talking specifically about files open by the Finder. Now
>> >> he's trying to change the topic to general Finder bugs. Lame.
>> >> That's not what we are discussing here. Nice try, but no cigar,
>> >> mr.know-it-all.
>> >
>> > actually it is what is being discussed. 
>> > or have you already forgotten that *you* said finder was not
>> > fragile? 
>> >
>> > typical for you, when facts are shoved in your face, you get all
>> > bent out of shape.
>> 
>> DING DING DING! Straw man again! mr.know-it-all bullheadedly
>> continues insisting that we were talking about Finder bugs in general
>> when it's clear as day that my statement, in context with the
>> entirety of this thread, is about force quitting Finder and resulting
>> file malformation/corruption.
>
> you said finder is not fragile, without any facts to back up your
> claim.

mr.weasel just *loves* to take statements out of context and try to
distort the conversation! My comment about Finder not bing fragile was,
in context, about it not being so fragile when it comes to *corrupting
files* (which is what we have been discussing for a couple days now in
this thread). But weasel boy wants to ignore that and make it about
general Finder bugginess, because that's a distraction from the actual
topic at hand. Silly weasel, tricks are for kids!

>> He has to do this, because he knows he has no valid argument about
>> the topic at hand.  So he tries to change the topic of discussion.
>> Lame. Keep digging, you silly weasel boy!
>
> i haven't changed anything. you are a liar.

Keep on digging, weasel boy!

-- 
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR

[toc] | [prev] | [next] | [standalone]

#57050

Have you tried adjusting the volume control?  Boom Boom!

-- 
Loading new sig message
Please wait..........

[toc] | [prev] | [next] | [standalone]

#56817

On 2014.02.21, 13:07 , nospam wrote:
> In article <bmpf4dF1uueU2@mid.individual.net>, Jolly Roger
> <jollyroger@pobox.com> wrote:
>
>> To expand on this, force quitting an application can cause any file that
>> the application currently has open to become corrupt, since it does not
>> give the application a chance to finish updating the file in question
>> and close it before quitting. Applications may have their own preference
>> files open, or other files on your startup volume. If an application's
>> preference file becomes malformed or corrupt, it can cause the
>> application in question to behave in unpredictable ways on subsequent
>> launches.
>
> that's possible, but very unlikely because files are written atomically.
>
> you might lose changes you made since the last save, but that's about
> it. it's extremely unlikely that anything will be corrupted.

I have to agree with J-R although we don't usually agree on very much.

Apps only do as the programmer programmed.  I've written apps where 
files remain open for weeks - that includes random access read/writeable 
files (simple flat databases, if you will).  Certainly data recorders 
with files open for hours or even days at a time.  No ill came from it 
(DOS, Windows).

Log files can be left open or closed then appended to - but in large 
projects it's quite common to have many files open for write at a given 
time.  Makes it easy to simply keep all the closures for the cleanup 
code when the program exits.

Some files (Maintenance of config files for example) owned by an 
application are usually written and closed in one go.  That's appropriate.

OS X is also a collection of "middleware apps".  lsof-ing the system 
disk shows a large number of files opened at any given time.  (As well 
as by whatever apps happen to be running).

-- 
   Those who have reduced our privacy, whether they are state
   or commercial actors, prefer that we do not reduce theirs.
                  - Jaron Lanier, Scientific American, 2013.11.

[toc] | [prev] | [next] | [standalone]

#56821

In article <frydnZ7hS4i0fJrOnZ2dnUVZ_r2dnZ2d@giganews.com>, Alan Browne
<alan.browne@FreelunchVideotron.ca> wrote:

> >> To expand on this, force quitting an application can cause any file that
> >> the application currently has open to become corrupt, since it does not
> >> give the application a chance to finish updating the file in question
> >> and close it before quitting. Applications may have their own preference
> >> files open, or other files on your startup volume. If an application's
> >> preference file becomes malformed or corrupt, it can cause the
> >> application in question to behave in unpredictable ways on subsequent
> >> launches.
> >
> > that's possible, but very unlikely because files are written atomically.
> >
> > you might lose changes you made since the last save, but that's about
> > it. it's extremely unlikely that anything will be corrupted.
> 
> I have to agree with J-R although we don't usually agree on very much.
> 
> Apps only do as the programmer programmed.  I've written apps where 
> files remain open for weeks - that includes random access read/writeable 
> files (simple flat databases, if you will).  Certainly data recorders 
> with files open for hours or even days at a time.  No ill came from it 
> (DOS, Windows).

lots of apps leave files open. that is not the problem.

the issue is what happens on a force-quit and almost always, the only
data that is lost is anything changed since the last save.

many apps autosave so the amount of loss is minimal, if anything. 

it's extremely unlikely that the files will be corrupted.

that's not to say it can't ever happen, but it's relatively rare.

[toc] | [prev] | [next] | [standalone]

#56824

On 2014.02.22, 00:29 , nospam wrote:
> In article <frydnZ7hS4i0fJrOnZ2dnUVZ_r2dnZ2d@giganews.com>, Alan Browne
> <alan.browne@FreelunchVideotron.ca> wrote:
>
>>>> To expand on this, force quitting an application can cause any file that
>>>> the application currently has open to become corrupt, since it does not
>>>> give the application a chance to finish updating the file in question
>>>> and close it before quitting. Applications may have their own preference
>>>> files open, or other files on your startup volume. If an application's
>>>> preference file becomes malformed or corrupt, it can cause the
>>>> application in question to behave in unpredictable ways on subsequent
>>>> launches.
>>>
>>> that's possible, but very unlikely because files are written atomically.
>>>
>>> you might lose changes you made since the last save, but that's about
>>> it. it's extremely unlikely that anything will be corrupted.
>>
>> I have to agree with J-R although we don't usually agree on very much.
>>
>> Apps only do as the programmer programmed.  I've written apps where
>> files remain open for weeks - that includes random access read/writeable
>> files (simple flat databases, if you will).  Certainly data recorders
>> with files open for hours or even days at a time.  No ill came from it
>> (DOS, Windows).
>
> lots of apps leave files open. that is not the problem.
>
> the issue is what happens on a force-quit and almost always, the only
> data that is lost is anything changed since the last save.

What I wrote was in reply your claim:
"... very unlikely because files are written atomically."

Some are.  Some are not.  lsof your system disk with some general apps 
open.  Oops.  Correction: many are not.

-- 
   Those who have reduced our privacy, whether they are state
   or commercial actors, prefer that we do not reduce theirs.
                  - Jaron Lanier, Scientific American, 2013.11.

[toc] | [prev] | [next] | [standalone]

#56825

On 2014.02.22, 10:02 , Alan Browne wrote:
> On 2014.02.22, 00:29 , nospam wrote:
>> In article <frydnZ7hS4i0fJrOnZ2dnUVZ_r2dnZ2d@giganews.com>, Alan Browne
>> <alan.browne@FreelunchVideotron.ca> wrote:
>>
>>>>> To expand on this, force quitting an application can cause any file
>>>>> that
>>>>> the application currently has open to become corrupt, since it does
>>>>> not
>>>>> give the application a chance to finish updating the file in question
>>>>> and close it before quitting. Applications may have their own
>>>>> preference
>>>>> files open, or other files on your startup volume. If an application's
>>>>> preference file becomes malformed or corrupt, it can cause the
>>>>> application in question to behave in unpredictable ways on subsequent
>>>>> launches.
>>>>
>>>> that's possible, but very unlikely because files are written
>>>> atomically.
>>>>
>>>> you might lose changes you made since the last save, but that's about
>>>> it. it's extremely unlikely that anything will be corrupted.
>>>
>>> I have to agree with J-R although we don't usually agree on very much.
>>>
>>> Apps only do as the programmer programmed.  I've written apps where
>>> files remain open for weeks - that includes random access read/writeable
>>> files (simple flat databases, if you will).  Certainly data recorders
>>> with files open for hours or even days at a time.  No ill came from it
>>> (DOS, Windows).
>>
>> lots of apps leave files open. that is not the problem.
>>
>> the issue is what happens on a force-quit and almost always, the only
>> data that is lost is anything changed since the last save.
>
> What I wrote was in reply your claim:
> "... very unlikely because files are written atomically."
>
> Some are.  Some are not.  lsof your system disk with some general apps
> open.  Oops.  Correction: many are not.

Clarification: meant "many are not closed".


-- 
   Those who have reduced our privacy, whether they are state
   or commercial actors, prefer that we do not reduce theirs.
                  - Jaron Lanier, Scientific American, 2013.11.

   Privacy has become an essential personal chore that most
   people are not trained to perform.
                  - Jaron Lanier, Scientific American, 2013.11.

    ... it may be that "in the cloud" really isn't the best term
    for the services these companies offer.  What they really
    want is to have us "on the leash."
                   -David Pogue, Scientific American, 2014.02

[toc] | [prev] | [next] | [standalone]

#56828

On 2014-02-22, Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
> On 2014.02.22, 10:02 , Alan Browne wrote:
>>
>> What I wrote was in reply your claim:
>> "... very unlikely because files are written atomically."
>>
>> Some are.  Some are not.  lsof your system disk with some general apps
>> open.  Oops.  Correction: many are not.
>
> Clarification: meant "many are not closed".

And of all those that are left open, we have no idea which are or are
not written atomically. That's the fact. Weasel boy wants us to ignore
this fact.

-- 
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR

[toc] | [prev] | [next] | [standalone]

#56829

On 2014.02.22, 12:01 , Jolly Roger wrote:
> On 2014-02-22, Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
>> On 2014.02.22, 10:02 , Alan Browne wrote:
>>>
>>> What I wrote was in reply your claim:
>>> "... very unlikely because files are written atomically."
>>>
>>> Some are.  Some are not.  lsof your system disk with some general apps
>>> open.  Oops.  Correction: many are not.
>>
>> Clarification: meant "many are not closed".
>
> And of all those that are left open, we have no idea which are or are
> not written atomically. That's the fact. Weasel boy wants us to ignore
> this fact.

Inconvenient truths never stopped him.

-- 
   Those who have reduced our privacy, whether they are state
   or commercial actors, prefer that we do not reduce theirs.
                  - Jaron Lanier, Scientific American, 2013.11.

[toc] | [prev] | [next] | [standalone]

#56830

On 2014-02-22, Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
> On 2014.02.22, 12:01 , Jolly Roger wrote:
>> On 2014-02-22, Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
>>> On 2014.02.22, 10:02 , Alan Browne wrote:
>>>>
>>>> What I wrote was in reply your claim:
>>>> "... very unlikely because files are written atomically."
>>>>
>>>> Some are.  Some are not.  lsof your system disk with some general apps
>>>> open.  Oops.  Correction: many are not.
>>>
>>> Clarification: meant "many are not closed".
>>
>> And of all those that are left open, we have no idea which are or are
>> not written atomically. That's the fact. Weasel boy wants us to ignore
>> this fact.
>
> Inconvenient truths never stopped him.

Incidentally, one in particular I've noticed stays open a lot if Safari's
bookmarks.plist file, which probably explains why my Safari bookmarks
have so many freaking duplicate and missing items in it from time to
time! Lucky I have backups. Grrr, Apple...

-- 
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR

[toc] | [prev] | [next] | [standalone]

#56831

On 2014.02.22, 12:16 , Jolly Roger wrote:

> Incidentally, one in particular I've noticed stays open a lot if Safari's
> bookmarks.plist file, which probably explains why my Safari bookmarks
> have so many freaking duplicate and missing items in it from time to
> time! Lucky I have backups. Grrr, Apple...

Never liked Safari.  My peeve is actually that the "favourites bar" does 
not show site icons.  Almost all of my favourites are well represented 
by the icon.  Does not take much room so lots of icons.
Chrome:
https://www.dropbox.com/s/t1y2o12p8tyiw8u/Screen%20Shot%202014-02-22%20at%2012.31.21.jpg

But no, the idiots at Apple insist on text so it takes longer to find a 
given mark - I do abbreviate them, but still it's just plain ugly.

I do use Safari to watch Netflix now as Chrome doesn't play perfect with 
Netflix for some content.  (I pipe the Mac to the Apple TV to the big 
screen and use the Apple keyboard and mouse (bluetooth) to control the 
mac from that room.  Kinda nifty really).

-- 
   Those who have reduced our privacy, whether they are state
   or commercial actors, prefer that we do not reduce theirs.
                  - Jaron Lanier, Scientific American, 2013.11.

[toc] | [prev] | [next] | [standalone]

#56845

On 2014-02-22, Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
> On 2014.02.22, 12:16 , Jolly Roger wrote:
>
>> Incidentally, one in particular I've noticed stays open a lot if Safari's
>> bookmarks.plist file, which probably explains why my Safari bookmarks
>> have so many freaking duplicate and missing items in it from time to
>> time! Lucky I have backups. Grrr, Apple...
>
> Never liked Safari.  My peeve is actually that the "favourites bar" does 
> not show site icons.  Almost all of my favourites are well represented 
> by the icon.  Does not take much room so lots of icons.
> Chrome:
> https://www.dropbox.com/s/t1y2o12p8tyiw8u/Screen%20Shot%202014-02-22%20at%2012.31.21.jpg

I like it. 

> But no, the idiots at Apple insist on text so it takes longer to find a 
> given mark - I do abbreviate them, but still it's just plain ugly.

Agreed. I tend to place folders there to group them. That helps; but it
would be nice to have the option of using icons instead.

-- 
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR

[toc] | [prev] | [next] | [standalone]

#56851

In message <-9KdnQ05Sfk3QpXOnZ2dnUVZ_sKdnZ2d@giganews.com> 
  Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
> I do use Safari to watch Netflix now as Chrome doesn't play perfect with 
> Netflix for some content.  (I pipe the Mac to the Apple TV to the big 
> screen and use the Apple keyboard and mouse (bluetooth) to control the 
> mac from that room.  Kinda nifty really).

You use you mac to watch netflix that you send to your appletv?

Why not use netflix on the AppleTV?

-- 
If you must choose between two evils, pick the one you've never tried
before.

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.sys.mac.system

csiph-web