 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Mac Forum / Country Specific / UK Mac Group / May 2008Warning: Finder doesn't save immediately
This may be common knowledge, but it wasn't mine. Since the Finder is just another database manager (the file system is essentially a database) you might naively believe that the Finder will save the changes you make immediately. It doesn't. (as I found out) Changes get written to disk only when you close the window. So, if you have a kernel panic for example, all changes you made in windows that are still open will be lost. If you walk away after having done a lot of work in the Finder it is best to close all windows you have been working in. In the worst case you may even lose files, Jan > This may be common knowledge, but it wasn't mine. > [quoted text clipped - 13 lines] > > Jan Really? I didn't know that. I usually have loads of finder windows open. So I ought to press apple-w. Specifically what Finder actions does this apply to? - renaming? - moving files? - colour labelling files This is also a bitch when you are using PGP disk encryption. if you get a kernel panic you really are f.cked. you have to eject the drive to 'save' the contents of the disk. > > This may be common knowledge, but it wasn't mine. > > [quoted text clipped - 16 lines] > Really? I didn't know that. I usually have loads of finder windows > open. So I ought to press apple-w. I didn't know either. > Specifically what Finder actions does this apply to? > - renaming? > - moving files? > - colour labelling files All of them, I guess. Hard to experiment though. I noticed just in time some files had gone so I could still rescue them from the back up. I have indeed changed my working habits when reorganising large folders, Jan >This may be common knowledge, but it wasn't mine. > [quoted text clipped - 5 lines] > >Changes get written to disk only when you close the window. This doesn't seem to be the case with renames, deletes, copies or moves - all such changes are visible from a terminal instantly, so it's not Finder that's caching any changes. It may still be the case that filesystem changes made are cached in memory and only written out to the filesystem in a lazy fashion - and this will be true for all processes (except `sync`!). Do you have a reference to more detailed analysis? Cheers - Jaimie  SignatureSquawk! Pieces of Nine! Squawk! Pieces of Nine! SYSTEM HALTED - PARROTTY ERROR. > >This may be common knowledge, but it wasn't mine. > > [quoted text clipped - 9 lines] > moves - all such changes are visible from a terminal instantly, so > it's not Finder that's caching any changes. No need for the Terminal. The Finder itself says so. > It may still be the case that filesystem changes made are cached in > memory and only written out to the filesystem in a lazy fashion - and > this will be true for all processes (except `sync`!). That's the point I guess. The Finder seems to keep all changes in RAM, and writes them to disk only when you close the window. The Terminal clerly has to ask the Finder for changes to open windows. You wouldn't want it to report the old state of affairs before any changes were made. > Do you have a reference to more detailed analysis? No, just an unpleasant experience, And a warning to check allwindows that were open at the time of a crash. (as far as you can remember) Best, Jan > That's the point I guess. > The Finder seems to keep all changes in RAM, > and writes them to disk only when you close the window. > The Terminal clerly has to ask the Finder for changes to open windows. Eh? That's really not right. The Finder is just an application, no more or less than the programs you're running in the terminal. Programs do *not* ask the Finder anything about the state of the disks. I think what you're seeing is that the Finder really doesn't update something ("Apply" changes) until you move the text focus out of the field, or click out of the inspector window, or something similar. Lazy updates, IYSWIM. Cheers, Chris > > That's the point I guess. > > The Finder seems to keep all changes in RAM, [quoted text clipped - 6 lines] > less than the programs you're running in the terminal. Programs do > *not* ask the Finder anything about the state of the disks. I don't know how Apple engineered it. However, the file system is a database, and if you manage that by independent applications conflicts may arise. > I think what you're seeing is that the Finder really doesn't update > something ("Apply" changes) until you move the text focus out of the > field, or click out of the inspector window, or something similar. Lazy > updates, IYSWIM. The database could consist of a data on disk, and pending modifications in RAM. Just guessing, Jan > > > That's the point I guess. > > > The Finder seems to keep all changes in RAM, [quoted text clipped - 20 lines] > and pending modifications in RAM. > Just guessing, That would also be my guess. My understanding is that the OS-X does a lot of buffering of disk access, i.e., if you access disk it reads the relevant pages from disk to RAM, does the requested manipulations, and sometimes waits with writing them back to disk until it thinks nobody will do more operations on that page or if it needs the RAM back to buffer other disk pages. If that is correct then this has nothing to do with independent applications not committing their updates and not just Finder but any application will have this problem. In principle enabling journaling can improve the situation, because then all updates are immediately written to a special journal file on disk, but it depends on some details I don't know if it completely prevents any loss of data. -- Jan Hidders > > > That's the point I guess. > > > The Finder seems to keep all changes in RAM, [quoted text clipped - 11 lines] > and if you manage that by independent applications > conflicts may arise. Er, it's how desktop computers have worked for quite a while now. You have the OS itself, which handles all the operations of the system (never!), such as moving and saving of files. However, until a file has been completely written to a permanent storage media, such as a hard drive, it can be lost at any time before it's saved from RAM. Any bottle neck in the system, slow RAM, slow HD, slow controlling processors, increase the risk. Finder is just a User Interface to make it easy to control the OS. It does not actually do any of the tasks itself, but just send the commands that it interprets from your input. Once that command it send, then it's out of Finder's control if the underlying OS mucks it up. FWIW, it's the same with Windows or Linux, or any OS that has some kind of user friendly interface. > > I think what you're seeing is that the Finder really doesn't update > > something ("Apply" changes) until you move the text focus out of the [quoted text clipped - 4 lines] > and pending modifications in RAM. > Just guessing, What you see on screen will be data stored in RAM. It gets shunted around between RAM and disk depending on whether it's needed at that time or not - this does depend on the software though, some may load entire data into RAM before it can work - an Appleworks database, for example, is loaded entirely into RAM when it's in use, and has to be saved (manually) back to disk after being modified. A disk filing system is essentially just a database, with data stored and a directory to locate the data. The OS scans the directory to find the data. In order to save anything it has to write the data to disk and modify the directory. If you switch off before the directory is modified, then you'll lose access to that data. A very long time ago I stopped using the 'Move' command and always copy and delete files. This ensures that I will have access to a copy of a file, in one location or the other, in the event of a problem. I have noticed that Finder lists do take a while to update at times - add a new item in any folder, and it can take a while before it updates - sometimes only after another change is made - but it does happen eventually. I'm actually finding quite amusing that you haven't mentioned the fact that having to close a window (command-w) in order to save something is so 'un-maclike'. SignatureAndy Hewitt <http://web.mac.com/andrewhewitt1/> <snip> > A disk filing system is essentially just a database, with data stored > and a directory to locate the data. The OS scans the directory to find > the data. In order to save anything it has to write the data to disk and > modify the directory. If you switch off before the directory is > modified, then you'll lose access to that data. I think you are either employing a great deal of poetic licence or you are mistaken. The file system is *not* a database. It lives at a lower level in the OS. Any normal database makes at least nominal use of the file system. The switch-off has to be a catastrophic loss of power or a panic. A normal shutdown flushes all to disk. Furthermore, the default file system now (Tiger and beyond) employs a journal, which writes everything to disk immediately, or at least during power fail processing, just not in the right place, so even a catastrophic loss of power has no permanent effect after the next start up. Which is what proper operating systems like VMS have done since time immemorial. Unix had a bad reputation in that regard for oh, 30 years, but it is more or less fixed now. > A very long time ago I stopped using the 'Move' command and always copy > and delete files. This ensures that I will have access to a copy of a > file, in one location or the other, in the event of a problem. You can probably start using move again. You are protecting against a non-existent threat. > I have noticed that Finder lists do take a while to update at times - > add a new item in any folder, and it can take a while before it updates > - sometimes only after another change is made - but it does happen > eventually. Whether the Finder reports it correctly is more or less irrelevant, except for the numpty's peace of mind. Watch the Finder's view of an external volume on another machine if you don't believe me. It will stay wrong indefinitely until encouraged to update itself regardless of having files ripped out from under it on the other host. > I'm actually finding quite amusing that you haven't mentioned the fact > that having to close a window (command-w) in order to save something is > so 'un-maclike'. Eh? Is that not how it has always been? An application can force a flush any time it likes, but there is no point in being silly about it. That just wastes resources. SignatureTo de-mung my e-mail address:- fsnospam$elliott$$ PGP Fingerprint: 1A96 3CF7 637F 896B C810 E199 7E5C A9E4 8E59 E248 > <snip> > > A disk filing system is essentially just a database, with data stored [quoted text clipped - 8 lines] > The switch-off has to be a catastrophic loss of power or a panic. A > normal shutdown flushes all to disk. Yes, that's right. I said 'switch off', and not 'shutdown'. Whether that's you turning off the mains or a power cut doesn't matter. > Furthermore, the default file system now (Tiger and beyond) employs a > journal, which writes everything to disk immediately, or at least [quoted text clipped - 3 lines] > time immemorial. Unix had a bad reputation in that regard for oh, 30 > years, but it is more or less fixed now. Yes, I know about the journaling system. But even a power failure must cause a failure to save if the data is still in memory. Surely even journaling has to work with the same processes of writing to disk from memory, and a power failure during that process surely must result in unsaved data. OK, the chances are small as the speed of writing, and the delays in processing it are getting better. > > A very long time ago I stopped using the 'Move' command and always copy > > and delete files. This ensures that I will have access to a copy of a > > file, in one location or the other, in the event of a problem. > You can probably start using move again. You are protecting against a > non-existent threat. Hmm, there's still a small chance though. > > I have noticed that Finder lists do take a while to update at times - > > add a new item in any folder, and it can take a while before it updates [quoted text clipped - 5 lines] > stay wrong indefinitely until encouraged to update itself regardless of > having files ripped out from under it on the other host. That's not something I get to do here, but I understand what you're saying. > > I'm actually finding quite amusing that you haven't mentioned the fact > > that having to close a window (command-w) in order to save something is [quoted text clipped - 3 lines] > any time it likes, but there is no point in being silly about it. That > just wastes resources. Oh, that was just a little dig at Jan's original post and his past comments about MacSOUP. SignatureAndy Hewitt <http://web.mac.com/andrewhewitt1/> <snip> > Yes, I know about the journaling system. But even a power failure must > cause a failure to save if the data is still in memory. Surely even [quoted text clipped - 4 lines] > OK, the chances are small as the speed of writing, and the delays in > processing it are getting better. I don't know whether OS X does it, but systems I'm more familiar with assert an interrupt as the power starts dropping. The processor scampers to get the last of the journal onto disk with the remaining energy in the power supply. Those last few ms are pretty exciting. You probably get 100 of them, which is lots really. Regardless of its success, a fsck always runs on next start, and stuff is tidied up as best it can. Of course none of this helps an application that had not yet decided to write stuff back to disk that it should have, so yanking the power at arbitrary moments to make a debating point is a less than safe way of leaving your desk.. Some OS's pass power-down signals to user processes to give them a chance to die gracefully. I guess those need bigger capacitors in their power supplies. PS. I can't find too much on OS X power fail processing on the web or in my manual heap. Does anyone know for sure whether a powerfail interrupt occurs and what the OS does with it? SignatureTo de-mung my e-mail address:- fsnospam$elliott$$ PGP Fingerprint: 1A96 3CF7 637F 896B C810 E199 7E5C A9E4 8E59 E248 > <snip> > > Yes, I know about the journaling system. But even a power failure must [quoted text clipped - 27 lines] > in my manual heap. Does anyone know for sure whether a powerfail > interrupt occurs and what the OS does with it? Hmm, capacitors are a bid of a sore point in G5s, they are known to fail, mine did last year - make quite a loud pop too. If it does have a power failure, my G5 does seem to be 'off' pretty instantly. Cheers. SignatureAndy Hewitt <http://web.mac.com/andrewhewitt1/> <snip> > > Some OS's pass power-down signals to user processes to give them a > > chance to die gracefully. I guess those need bigger capacitors in their [quoted text clipped - 7 lines] > fail, mine did last year - make quite a loud pop too. If it does have a > power failure, my G5 does seem to be 'off' pretty instantly. I got a bit further into it since my last post. Intel has the hardware for power-fail interrupts (unsure whether it is processor or mother board - I suspect the latter, or perhaps it is part of support hardware like the real time clock (Nat Semi make such a device) but the interrupt comes in at the second highest priority, just below a bus check, but above the clock. Windows NT and all its subsequent re-namings does have OS support for power-fail run-down. Mostly for drivers so they can get their house in order as the machine dies and also when it recovers. There are at least two flavours of journalling. Either complete writes are journalled or simply a list of inodes that have been 'dirtied' recently gets journalled. I'm pretty sure OS X does the latter. That makes a huge improvement on restart time file consistency checking but doesn't do much for getting the last dregs of buffers onto disk on the way down. The rest of the reading I did seems to indicate that desktop-ish PC class hardware is pretty rubbish at power fail processing and that a UPS is a good idea if you care about your data. SignatureTo de-mung my e-mail address:- fsnospam$elliott$$ PGP Fingerprint: 1A96 3CF7 637F 896B C810 E199 7E5C A9E4 8E59 E248 > <snip> > > > Some OS's pass power-down signals to user processes to give them a [quoted text clipped - 24 lines] > doesn't do much for getting the last dregs of buffers onto disk on the > way down. Interesting stuff. So it generally seems uncertain that data is safe in the event of a power failure then. Much better than things used to be, but still not perfect. > The rest of the reading I did seems to indicate that desktop-ish PC > class hardware is pretty rubbish at power fail processing and that a > UPS is a good idea if you care about your data. Aye, I have a UPS myself. I do quite a bit of photo editing, and could be really upset if any got corrupted (I have plenty of backups though). SignatureAndy Hewitt <http://web.mac.com/andrewhewitt1/> <snip> > Interesting stuff. So it generally seems uncertain that data is safe in > the event of a power failure then. Much better than things used to be, > but still not perfect. Yep. There might be stuff that would have been nice to have been written but wasn't, but at least we know for sure whether it was or wasn't successfully written. > > The rest of the reading I did seems to indicate that desktop-ish PC > > class hardware is pretty rubbish at power fail processing and that a > > UPS is a good idea if you care about your data. > > Aye, I have a UPS myself. I do quite a bit of photo editing, and could > be really upset if any got corrupted (I have plenty of backups though). Heh! Guess who is writing his Aperture Vault to a pile of DVDs while we chat. SignatureTo de-mung my e-mail address:- fsnospam$elliott$$ PGP Fingerprint: 1A96 3CF7 637F 896B C810 E199 7E5C A9E4 8E59 E248 > <snip> > > Interesting stuff. So it generally seems uncertain that data is safe in [quoted text clipped - 3 lines] > written but wasn't, but at least we know for sure whether it was or > wasn't successfully written. I wonder how hard it would be to add a system in that would keep RAM powered for a while, just enough to store any unsaved data until power was restored. > > > The rest of the reading I did seems to indicate that desktop-ish PC > > > class hardware is pretty rubbish at power fail processing and that a [quoted text clipped - 5 lines] > Heh! Guess who is writing his Aperture Vault to a pile of DVDs while we > chat. That reminds me, I didn't do my last monthly backup to DVD. I have been cancelling those, as for some reason Backup isn't keep a track of them and is making new backups each month, rather than an incremental one. SignatureAndy Hewitt <http://web.mac.com/andrewhewitt1/> <snip> > That reminds me, I didn't do my last monthly backup to DVD. I have been > cancelling those, as for some reason Backup isn't keep a track of them > and is making new backups each month, rather than an incremental one. Time to start again then. When the pile of incrmentals is just too big, just add another plan. You'll be happy if you ever need to do a restore. SignatureTo de-mung my e-mail address:- fsnospam$elliott$$ PGP Fingerprint: 1A96 3CF7 637F 896B C810 E199 7E5C A9E4 8E59 E248 > <snip> >> That reminds me, I didn't do my last monthly backup to DVD. I have been [quoted text clipped - 4 lines] > just add another plan. You'll be happy if you ever need to do a > restore. That's basically what I've had to just do, because my initial plan just stopped working. Backup's a piece of junk, really, but there's not much else around that's any better. What do you do with the "dead" plans at that point - delete 'em (and their valuable history)? Cheers, Chris > > <snip> > >> That reminds me, I didn't do my last monthly backup to DVD. I have been [quoted text clipped - 11 lines] > What do you do with the "dead" plans at that point - delete 'em (and > their valuable history)? I leave 'em on disk till I need the space. There is not much point doing anything else. Recovering the most recent is a waste of time, since that will be very similar to the new plan's first full backup. Keeping all the incrementals as a poor man's Time Machine is less useful as time goes by. I quite like Backup. I slurp stuff from all the various Macs lying about the house every night onto one big disk. Then I use DVD plans monthly to deal with offsite backup. Except that is very tiresome. Where are the 1TB DVDs I need? My iTunes plan is 32 DVDs Blecch! I give up. Buying more disk instead. SignatureTo de-mung my e-mail address:- fsnospam$elliott$$ PGP Fingerprint: 1A96 3CF7 637F 896B C810 E199 7E5C A9E4 8E59 E248 >>> <snip> >>>> That reminds me, I didn't do my last monthly backup to DVD. I have been [quoted text clipped - 15 lines] > doing anything else. Recovering the most recent is a waste of time, > since that will be very similar to the new plan's first full backup. True, it is just a bit of a clutter. > Keeping all the incrementals as a poor man's Time Machine is less > useful as time goes by. Nod, but it is obviously much quicker than doing a full backup :-) > I quite like Backup. I slurp stuff from all the various Macs lying > about the house every night onto one big disk. Then I use DVD plans > monthly to deal with offsite backup. Except that is very tiresome. > Where are the 1TB DVDs I need? > My iTunes plan is 32 DVDs > Blecch! I give up. Buying more disk instead. How about BluRay discs? Cheers, Chris <snip> > > Keeping all the incrementals as a poor man's Time Machine is less > > useful as time goes by. > > Nod, but it is obviously much quicker than doing a full backup :-) Sure, but restore gets *very* silly with 100 incrementals totalling 10 fulls. (Still bearable if you restore very infrequently) > > I quite like Backup. I slurp stuff from all the various Macs lying > > about the house every night onto one big disk. Then I use DVD plans [quoted text clipped - 4 lines] > > How about BluRay discs? At £8 for 25GB you might as well keep buying 250GB disks for £78 with added convenience, speed and re-usability. Blu-ray is too little too late. Pretty well stillborn technology. They spent too long duking it out with HD-DVD. It was going to take about 10 hours to back up my iTunes to 30 DVDs. It took 50 minutes disk to disk. Blu-ray 2x is 72Mb/s or a measly 9MB/sec, I still need to play postman 6 times and have to wait for a verify pass on each disk. It would take 8 hours to get all 130GB of itunes onto Blu-ray. Now consider recovering a single tune: 4 hours v 4 seconds. Hopeless! Wake me up when I can buy 1TB opticals with a read and write speed around 100 MB/sec that cost less than 10p per GB. I bought 50 DVDs for £8 yesterday. That's 4p/GB. Ordinary disks have Blu-ray snookered at the high end and DVDs with very similar performance have Blu-ray cornered at the low end. SignatureTo de-mung my e-mail address:- fsnospam$elliott$$ PGP Fingerprint: 1A96 3CF7 637F 896B C810 E199 7E5C A9E4 8E59 E248 > At £8 for 25GB you might as well keep buying 250GB disks for £78 with > added convenience, speed and re-usability. I just bought a 500GB Western Digital MyBook disk for £65 (inc delivery) from Amazon. So it's even better than that.... -z- Signature"Ignorance more frequently begets confidence than does knowledge." - Charles Darwin >> At £8 for 25GB you might as well keep buying 250GB disks for £78 with >> added convenience, speed and re-usability. > > I just bought a 500GB Western Digital MyBook disk for £65 (inc delivery) > from Amazon. So it's even better than that.... It feels "wrong" to have a real bit of actual electronics, and then park it on a shelf. Cheers, Chris > >> At £8 for 25GB you might as well keep buying 250GB disks for £78 with > >> added convenience, speed and re-usability. [quoted text clipped - 4 lines] > It feels "wrong" to have a real bit of actual electronics, and then > park it on a shelf. You haven't seen my shelves! SignatureWoody www.alienrat.com >>>> At £8 for 25GB you might as well keep buying 250GB disks for £78 with >>>> added convenience, speed and re-usability. [quoted text clipped - 6 lines] > > You haven't seen my shelves! I should have said working electronics... Cheers, Chris > >>>> At £8 for 25GB you might as well keep buying 250GB disks for £78 with > >>>> added convenience, speed and re-usability. [quoted text clipped - 8 lines] > > I should have said working electronics... Yes, working electronics. SignatureWoody www.alienrat.com > > > <snip> > > >> That reminds me, I didn't do my last monthly backup to DVD. I have been [quoted text clipped - 8 lines] > > stopped working. Backup's a piece of junk, really, but there's not much > > else around that's any better. Yes, Backup isn't all that reliable, but I use it to enhance Time Machine, and make backups of my user folder in other places too. Burning to DVD as well probably isn't really necessary. > > What do you do with the "dead" plans at that point - delete 'em (and > > their valuable history)? [quoted text clipped - 12 lines] > My iTunes plan is 32 DVDs > Blecch! I give up. Buying more disk instead. That's what I found now, I just get a larger drive, or at least another one - I currently have three external drives with backed up data on them, and most of it is at least duplicated. SignatureAndy Hewitt <http://web.mac.com/andrewhewitt1/> > In article <1ih09zm.qvi8qo65ixm3N%wildrover.a...@googlemail.com>, Andy > [quoted text clipped - 19 lines] > time immemorial. Unix had a bad reputation in that regard for oh, 30 > years, but it is more or less fixed now. Strictly speaking a filesystem IS a database. A database is a way of organising data in a logical structure for later retrieval. Most filesystems in use today are hierarchical model databases (they have volumes, folders, and files). Most people think of some kind of SQL driven relational model system when they think of databases, and while an SQL system is a database, not all databases are SQL systems. In article <26b69e88-e6e9-43ec-a627-1c1e03a03b47@d1g2000hsg.googlegroups.com>, > > In article <1ih09zm.qvi8qo65ixm3N%wildrover.a...@googlemail.com>, Andy > > [quoted text clipped - 29 lines] > when they think of databases, and while an SQL system is a database, > not all databases are SQL systems. You can probably see the excluded middle error in your logic already. Strictly speaking it ain't so. Every database I know sits on top of an operating system's file system. Every non-trivial operating system has at least one file system. A file system is generally a far simpler structure than even a trivial database. I agree there are many sorts of database other than relational ones, but they are all pretty much distinct from file systems. Some might regard the combination of Files-11 and RMS to be a database, and it certainly is far more capable than many of the excrescences that call themselves databases, but its makers insisted that Files-11 was a file system and RMS was a record management system. IBM's ancient System 38 had a similar blurring, and you could argue that even earlier IBM OS'es had hardware in place of a file system, but apart from these exceptions there is no merit in confusing a file system with a database. You are not free to re-define the terms simply because directory files act as indexes, and most databases contain indexes of one sort or another. The IT industry has always made a distinction. It is unhelpful to re-write that history. There is enough of a trend with "Web 2.0" and Exchange Server to hide the underlying file system from numpty users. But it is still there. SignatureTo de-mung my e-mail address:- fsnospam$elliott$$ PGP Fingerprint: 1A96 3CF7 637F 896B C810 E199 7E5C A9E4 8E59 E248 >Every database I know sits on top of an operating system's file system. "Proper" databases don't need to. The likes of Oracle and DB2 can run in raw disk mode for the data storage. Cheers - Jaimie Signature"Oh drat these computers, they're so naughty and so complex." -- Marvin the Martian >>> That's the point I guess. >>> The Finder seems to keep all changes in RAM, [quoted text clipped - 11 lines] > and if you manage that by independent applications > conflicts may arise. My only point was that the Finder is simply not special, and apps don't have to ask it about anything. This is in contrast to the classic Finder which was *incredibly* special and linked in to the inner workings of the OS, and apps really did have to talk to it. Cheers, Chris > you might naively believe that the Finder > will save the changes you make immediately. > It doesn't. (as I found out) Just out of interest Jan, what actually were you doing at the time and what got lost? I'm a little bemused that no-one seems to have asked this before offering their opinions. ;-) Regards, SignatureBruce Horrocks Surrey England (bruce at scorecrow dot com) > > you might naively believe that the Finder > > will save the changes you make immediately. [quoted text clipped - 5 lines] > I'm a little bemused that no-one seems to have asked this before > offering their opinions. ;-) Good question. As it happens, I was clearing out a lot of folders containing many files, with many of them duplicates. (mostly eBooks) Using File buddy as the primary tool, greatly recommended for the purpose. So, many windows open, many files transfered to other windows, many files trashed, t.rash emptied regularly I used to leave all those windows open, to continue on the next day. When a kernel panic interfered I noticed some files were missing, and not to be found in the Find. Had to restore from back up, but it is quite possible that some files have disapppeared into the black cyberhole forever. Under the circumstances it is hard to remember all one has been doing. I'll try some experiments next. Best, Jan > This may be common knowledge, but it wasn't mine. > [quoted text clipped - 11 lines] > > In the worst case you may even lose files, I've never come across behaviour like that, and I've had a lot of problems with my Macs over the years. For sure the Finder can lose track of trivial changes like window positioning, but I'd've thought that with journalling enabled, there's no chance of losing a file without malware of a hardware fault being involved. Rowland. SignatureRemove the animal for email address: rowland.mcdonnell@dog.physics.org Sorry - the spam got to me http://www.mag-uk.org http://www.bmf.co.uk UK biker? Join MAG and the BMF and stop the Eurocrats banning biking > > This may be common knowledge, but it wasn't mine. > > [quoted text clipped - 19 lines] > no chance of losing a file without malware of a hardware fault being > involved. A kernel panic usually is a hardware malfunction, Jan [snip] > A kernel panic usually is a hardware malfunction, Almost all the kernel panics I've met have been identified as software faults (specifically, in the Hermstedt ISDN TA driver). All four PowerMacs bought by us have suffered hardware failure: none of them suffered kernel panics due to the hardware failures. I see evidence for the truth being the opposite of your claim. Rowland. SignatureRemove the animal for email address: rowland.mcdonnell@dog.physics.org Sorry - the spam got to me http://www.mag-uk.org http://www.bmf.co.uk UK biker? Join MAG and the BMF and stop the Eurocrats banning biking In article <1ih2plw.1rdo8xnyf10alN%real-address-in-sig@flur.bltigibbet>, Rowland McDonnell <real-address-in-sig@flur.bltigibbet> wrote: > [snip] > [quoted text clipped - 7 lines] > > I see evidence for the truth being the opposite of your claim. You are both right. There are plenty of ways that dud memory, cache, bus, dma controllers could bring on a panic and a dud driver is probably the prime software reason for panics. My most recent panic was probably caused by an overheating XT1900 graphics card. Did the hardware corrupt memory or did the graphics driver mis-process an "I'm cookin' in here" warning? All it takes is for kernel mode software to run wild. A common cause would be executing a bad instruction, or leaping to the wrong address through a corrupted or miscomputed pointer. How they get corrupted could be caused by hardware or software. I bet none of us have enough evidence to say which of those is the more frequent. Fortunately on OS X and Macintosh, panics are extremely rare. SignatureTo de-mung my e-mail address:- fsnospam$elliott$$ PGP Fingerprint: 1A96 3CF7 637F 896B C810 E199 7E5C A9E4 8E59 E248 > In article > <1ih2plw.1rdo8xnyf10alN%real-address-in-sig@flur.bltigibbet>, Rowland [quoted text clipped - 27 lines] > I bet none of us have enough evidence to say which of those is the more > frequent. Fortunately on OS X and Macintosh, panics are extremely rare. Not if you have a flaky RAM chip. (just a bit too slow perhaps) Fortunately exchanging it will restore the blessed state of never a kernel panic at once, Jan [snip] > Not if you have a flaky RAM chip. > (just a bit too slow perhaps) > Fortunately exchanging it will restore > the blessed state of never a kernel panic at once, So you are suggesting that no kernel panic can be caused by a software bug? That's an interesting suggestion. Rowland. SignatureRemove the animal for email address: rowland.mcdonnell@dog.physics.org Sorry - the spam got to me http://www.mag-uk.org http://www.bmf.co.uk UK biker? Join MAG and the BMF and stop the Eurocrats banning biking > [snip] > [quoted text clipped - 7 lines] > > That's an interesting suggestion. Dear Rowland, -please- learn to quote correctly. You should not snip all context before a piece of text that was primarily a reaction to something, Jan > > [snip] > > [quoted text clipped - 11 lines] > You should not snip all context before a piece of text > that was primarily a reaction to something, Dear Jan, -Please- shove your head up your arse. Rowland. SignatureRemove the animal for email address: rowland.mcdonnell@dog.physics.org Sorry - the spam got to me http://www.mag-uk.org http://www.bmf.co.uk UK biker? Join MAG and the BMF and stop the Eurocrats banning biking > > > [snip] > > > [quoted text clipped - 15 lines] > > -Please- shove your head up your arse. FWIW, it was actually good advice. I've solved problems like yours by exchanging my RAM. -z- Signature"Ignorance more frequently begets confidence than does knowledge." - Charles Darwin > > [snip] > > [quoted text clipped - 10 lines] > You are both right. There are plenty of ways that dud memory, cache, > bus, dma controllers could bring on a panic I never denied that. > and a dud driver is > probably the prime software reason for panics. That's what I've been told. Oh yeah, I should have mentioned the kernel panics caused by a USB 2.0 card I had in my old 2G4 before it died. Probably driver problems - related to sleep/waking. > My most recent panic was probably caused by an overheating XT1900 > graphics card. Did the hardware corrupt memory or did the graphics > driver mis-process an "I'm cookin' in here" warning? Who can tell? > All it takes is for kernel mode software to run wild. A common cause > would be executing a bad instruction, or leaping to the wrong address [quoted text clipped - 3 lines] > I bet none of us have enough evidence to say which of those is the more > frequent. I've got enough evidence to be willing to bet that software problems are the biggest culprit. >Fortunately on OS X and Macintosh, panics are extremely rare. They used to be rather common. Rowland. SignatureRemove the animal for email address: rowland.mcdonnell@dog.physics.org Sorry - the spam got to me http://www.mag-uk.org http://www.bmf.co.uk UK biker? Join MAG and the BMF and stop the Eurocrats banning biking |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.