An open community 
of Macintosh users,
for Macintosh users.

FineTunedMac Dashboard widget now available! Download Here

Previous Thread
Next Thread
Print Thread
Permission Repairs Error Messages
#32722 01/29/15 06:30 AM
Joined: Aug 2009
MG2009 Offline OP
OP Offline

Joined: Aug 2009
Recently ran PR and got the following. Have not seen these appear before and am wondering what to make of them.


2015-01-28 22:01:10 -0800: Open error 5: “Input/output error” on Library/Application Support/Apple/Remote Desktop/Notify
2015-01-28 22:02:37 -0800: Warning: SUID file “System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent” has been modified and will not be repaired.
2015-01-28 22:04:04 -0800: Open error 5: “Input/output error” on private/var/root/Library/Preferences/com.apple.stackshot.plist
2015-01-28 22:04:39 -0800:

2015-01-28 22:04:39 -0800: Permissions repair complete


Is there something I need to fix or delete . . . or can these be safely ignored?

Thanks, again.

---------------------


** 17" MacBook Pro (early 2011) with Mavericks 10.9

Re: Permission Repairs Error Messages
MG2009 #32723 01/29/15 06:49 AM
Joined: Aug 2009
Likes: 15
Online

Joined: Aug 2009
Likes: 15
The SUID warning can be safely ignored, but I've never seen “Input/output error” mean anything other than that your hard drive has begun an ultimately fatal, downward, bad blocks spiral.

First, and most important, and without waiting for input from anybody else, make sure that you're fully backed up.

Next, if you've got a 3rd party utility that can run a surface scan, TechTool Deluxe (which you may have gotten with AppleCare), TechTool Pro, and Drive Genius come to mind, run it; it will give you a definitive answer. (Have you looked in Disk Utility to see your S.M.A.R.T. status?)

If you haven't got an appropriate utility and you're not averse to going into Terminal, I can post commands.

Edit: I wasn't aware that "Repair Permissions" returns I/O errors, but Google turns up a bunch of instances.

Edit 2: If you've replaced your HDD with an SSD...ignore this.

Last edited by artie505; 01/29/15 08:57 AM. Reason: Edit & Cleanup

The new Great Equalizer is the SEND button.

In Memory of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire
Re: Permission Repairs Error Messages
artie505 #32745 01/29/15 08:21 PM
Joined: Aug 2009
MG2009 Offline OP
OP Offline

Joined: Aug 2009
Thanks, artie.

DU says that my internal hard drive S.M.A.R.T. status is : Verified

Earlier this week, I did a zero-out pass before I re-installed MAVERICKS; then transferred files from the Time Machine EXHD backup.

I do not have any of the tools you mentioned. I am not adverse to using Terminal if the instructions are clear. (Don't be afraid of "taking down" to me . . . the simpler the better.) grin

Re: Permission Repairs Error Messages
MG2009 #32747 01/29/15 08:32 PM
Joined: Aug 2009
Offline

Joined: Aug 2009
Originally Posted By: MG2009
DU says that my internal hard drive S.M.A.R.T. status is : Verified


failing SMART is a very good indicator / confirmation of a bad hard drive.

It is, however, a horrible indicator of a good hard drive. DO NOT TRUST passing SMART to mean "the drive is ok".

I have seen (on occasions too numerous to count) drives that I knew were failing (io errors, tapping, failing to power up, overheating, hanging) whose SMART was still "pass". Many of these drives toggled status over to "fail" during data recovery. Some went to their grave saying "it's ok, I'm fine, really!"


I work for the Department of Redundancy Department
Re: Permission Repairs Error Messages
MG2009 #32750 01/29/15 08:53 PM
Joined: Aug 2009
Likes: 15
Online

Joined: Aug 2009
Likes: 15
Trust Virtual1: "Verified" S.M.A.R.T. is not a good indicator at all.

When you ran the zero pass you mapped out, i.e. put out of sight (Edit: i.e. out of use), any bad blocks that may have existed at the time, so the fact that you've apparently developed new ones since then is NOT a good sign at all.

I haven't got the time to post the Terminal commands at the moment, but I ought to be able to do so within a coupl'a hours.

Meantime... BACKUP!

Last edited by artie505; 01/29/15 08:59 PM. Reason: Remapped->Mapped out +

The new Great Equalizer is the SEND button.

In Memory of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire
Re: Permission Repairs Error Messages
artie505 #32754 01/29/15 09:35 PM
Joined: Aug 2009
MG2009 Offline OP
OP Offline

Joined: Aug 2009
I restarted my MBPro and re-ran DU. The "offending file" messages (i.e. stackshot and ARD notify) no longer appear in the latest log.

The only entry remaining is the SUID one for ARD - which I will, as suggested, ignore.

Still . . . if you want to take the time, the SCAN TERMINAL COMMANDS info would be useful if needed in the future.

Thanks.

Re: Permission Repairs Error Messages
MG2009 #32759 01/29/15 10:58 PM
Joined: Aug 2009
Likes: 15
Online

Joined: Aug 2009
Likes: 15
I dunno... I/O errors don't go away.

Under any circumstances, though, Disk Utility doesn't touch every block on a drive, only the ones with which it must deal to accomplish its task (but I can't guess why it may have touched those items in one pass and not another).

I very strongly urge you to run this command (I remembered the process being more complicated,) immediately, rather than rely on DU's results!

Copy and paste this into a Terminal window:

Code:
sudo dd if=/dev/rdisk0 of=/dev/null conv=noerror

Hit return, enter your password at the prompt (it will not be visible), and be prepared to wait "n" hours for the command to run its course, depending on how fast your MBP runs, how large your HDD is, and whether it runs at 5,400 or 7,200RPM.

The command runs in the background, so you don't have to quit working while it's doing its thing, and I again urge you to not be lazy! If the original I/O errors can be relied on (Edit: And there's absolutely no reason to believe they were spurious.), your HDD is liable to tank at any moment...most likely the worst one. tongue

Good luck! smile

Edit: Please take a screenshot of your completed Terminal session and post it so we can see precisely what's up with your MBP.

Last edited by artie505; 01/30/15 01:51 AM. Reason: Add password instructions +

The new Great Equalizer is the SEND button.

In Memory of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire
Re: Permission Repairs Error Messages
MG2009 #32769 01/30/15 02:07 AM
Joined: Aug 2009
Likes: 15
Online

Joined: Aug 2009
Likes: 15
Just in case you're not clear about what bad blocks are: Inside your HDD are metal platters that are coated with magnetic media to which data is written.

A bad block occurs when some of the magnetic media flakes off and all or some of the data written to a block becomes unreadable, and even if only a portion of a block is affected, you'll get an I/O error as respects the entire block if something tries to read it.

Disk Utility's original report says that it encountered such a condition on your HDD, and its subsequent report should absolutely not be considered an "all-clear".

Edit: The condition never gets better...only worse.

Last edited by artie505; 01/30/15 02:15 AM.

The new Great Equalizer is the SEND button.

In Memory of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire
Re: Permission Repairs Error Messages
artie505 #32774 01/30/15 03:43 AM
Joined: Aug 2009
MG2009 Offline OP
OP Offline

Joined: Aug 2009
Thanks, artie505.

I will run the command and let you know how it goes tomorrow . . . assuming its process will be complete in the next 24 hours (hehehe).

My HDD is 500 gb and runs at 7200 rpm.

P.S. Also, I just did my daily backup on the EXHD.

smile

Re: Permission Repairs Error Messages
MG2009 #32778 01/30/15 07:23 AM
Joined: Aug 2009
Likes: 15
Online

Joined: Aug 2009
Likes: 15
> My HDD is 500 gb and runs at 7200 rpm.

That's similar to what I'm running...should take in the range of 2 hours if there are no bad blocks, but bad ones take on the order of 20 seconds each to resolve, so the command could run for an awfully long time if you've got a multiplicity of them. (I threw in the towel on my daughter's Mac after something like 2,000 bad blocks and 15 hours.)

If the command is still running in the morning it'll be likely that it's encountered many bad blocks (You'll see it in the output.), and you can either hit control-C to stop the process or indulge your curiosity.

Under any circumstances, though, please be sure to copy & paste your final Terminal screen into a post.


The new Great Equalizer is the SEND button.

In Memory of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire
Re: Permission Repairs Error Messages
artie505 #32779 01/30/15 07:26 AM
Joined: Aug 2009
MG2009 Offline OP
OP Offline

Joined: Aug 2009

UPDATE: I thought I began the SCAN in Terminal using the command above (copied and pasted).

Over four hours later, I saw nothing going on. So I used CONTROL + C to end the process. This is all I got for a report :


Last login: Thu Jan 29 20:02:21 on console
XXXXXX - MacBook-Pro:~ XXXXXX$ sudo dd if=/dev/rdisk0 of=/dev/null conv=noerror
Password:
^C89609590+0 records in
89609590+0 records out
45880110080 bytes transferred in 11577.035875 secs (3963027 bytes/sec)
XXXXXXX-MacBook-Pro:~ XXXXXX$



Note: The Xs are where the User Name appeared.

Looks to me like no SCAN ran at all - unless ending the "scan" does not report any kind of log - Full or Partial.

Was the COMMAND I used the correct one?

Re: Permission Repairs Error Messages
MG2009 #32780 01/30/15 07:45 AM
Joined: Aug 2009
Likes: 15
Online

Joined: Aug 2009
Likes: 15
Yes, you ran the command correctly.

Code:
89609590+0 records in
89609590+0 records out
45880110080 bytes transferred in 11577.035875 secs (3963027 bytes/sec)

is its output, but "45880110080 bytes transferred" tells that it only examined 45GB of your HDD's 500GB, so, and I hate to say it, you'd better run it again and let it run its full course.

I'm clueless as to why it's running so slowly. confused

I should have said earlier that as/if it encounters bad blocks it will show an I/O error for each one; no output means that it's still doing its thing without having encountered any bad blocks.

Sorry if I caused any confusion.


The new Great Equalizer is the SEND button.

In Memory of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire
Re: Permission Repairs Error Messages
MG2009 #32781 01/30/15 07:54 AM
Joined: Aug 2009
Likes: 15
Online

Joined: Aug 2009
Likes: 15
I think the command is running so slowly because blocks are only 512 bytes each.

You can speed up the process by running this command

Code:
sudo dd if=/dev/rdisk0 of=/dev/null conv=noerror bs=10240000

which increases the size of blocks read to 10,240,000 bytes each.

It will not speed things up proportionally, but it will help.

Edit: I guess TechTook Pro somehow speeds up the process; I used it to scan my HDD just a coupl'a weeks ago, and it took about 2 hours. (Just checked...a bit more than 1 hour.)

Sorry about the wasted 3 hours. It was probably to your advantage to have stopped the process prematurely.

Last edited by artie505; 01/30/15 08:24 AM.

The new Great Equalizer is the SEND button.

In Memory of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire
Re: Permission Repairs Error Messages
artie505 #32786 01/30/15 12:57 PM
Joined: Aug 2009
Offline

Joined: Aug 2009
Originally Posted By: artie505

Copy and paste this into a Terminal window:

Code:
sudo dd if=/dev/rdisk0 of=/dev/null conv=noerror

Hit return, enter your password at the prompt (it will not be visible), and be prepared to wait "n" hours for the command to run its course, depending on how fast your MBP runs, how large your HDD is, and whether it runs at 5,400 or 7,200RPM.

The command runs in the background, so you don't have to quit working while it's doing its thing, and I again urge you to not be lazy! If the original I/O errors can be relied on (Edit: And there's absolutely no reason to believe they were spurious.), your HDD is liable to tank at any moment...most likely the worst one. tongue


I'll make an adjustment to that. DD runs VERY slowly 512 bytes per pass. Bump that up by increasing block size. OK to use any larger number, but keep it an even multiple of 512. I use 1024000 for approximately 1mb. (performance levels off when you reach about 250k) 512 vs 1024000 can be the difference between three days and two hours.

sudo dd if=/dev/rdisk0 of=/dev/null bs=1024000

you can leave conv=noerror on there if you want it to find all the bad blocks instead of stopping at the first one. but I'm a zero-tolerance-policy on io errors. One sends it to my trashcan or RMA box.

sudo dd if=/dev/rdisk0 of=/dev/null bs=1024000 conv=noerror

(you also correctly chose rdisk. some people use disk instead, and for some reason no one can explain, DD accesses character devices much faster than block devices)


Code:
mac-e1:~ root # dd if=/dev/rdisk0 bs=512 count=512000 of=/dev/null
512000+0 records in
512000+0 records out
262144000 bytes transferred in 18.989955 secs (13804351 bytes/sec)

mac-e1:~ root # dd if=/dev/rdisk0 bs=512000 count=512 of=/dev/null
512+0 records in
512+0 records out
262144000 bytes transferred in 0.395372 secs (663031416 bytes/sec)

mac-e1:~ root # dd if=/dev/disk0 bs=512000 count=512 of=/dev/null
512+0 records in
512+0 records out
262144000 bytes transferred in 2.552634 secs (102695490 bytes/sec)

13 / 663 / 102 MB/sec... the details really do make a big difference o_O
oops, this is on an iMac with an SSD, that's not what I was intending to test. let me do another...


Code:
MACLT:~ root # dd if=/dev/rdisk0 bs=512 count=512000 of=/dev/null
512000+0 records in
512000+0 records out
262144000 bytes transferred in 21.312791 secs (12299844 bytes/sec)

MACLT:~ root # dd if=/dev/rdisk0 bs=512000 count=512 of=/dev/null
512+0 records in
512+0 records out
262144000 bytes transferred in 0.439098 secs (597005841 bytes/sec)

MACLT:~ root # dd if=/dev/disk0 bs=512000 count=512 of=/dev/null
512+0 records in
512+0 records out
262144000 bytes transferred in 2.674647 secs (98010687 bytes/sec)

12 / 597 / 98 - this is on a retina SSD


Code:
mac-scan:~ root # dd if=/dev/rdisk0 bs=512 count=512000 of=/dev/null
512000+0 records in
512000+0 records out
262144000 bytes transferred in 75.715733 secs (3462213 bytes/sec)

mac-scan:~ root # dd if=/dev/rdisk0 bs=512000 count=512 of=/dev/null
512+0 records in
512+0 records out
262144000 bytes transferred in 2.251195 secs (116446601 bytes/sec)

mac-scan:~ root # dd if=/dev/disk0 bs=512000 count=512 of=/dev/null
512+0 records in
512+0 records out
262144000 bytes transferred in 7.251505 secs (36150289 bytes/sec)

3 / 116 / 36 THAT is more what I was expecting to see. 3 vs 116 for block size problem, 116 vs 36 for char/block device problem. But yeah... 3 MB/sec vs 116.



Curious to see the SSD suffers from the same blocksize/devtype issues with DD.


I work for the Department of Redundancy Department
Re: Permission Repairs Error Messages
Virtual1 #32799 01/30/15 06:54 PM
Joined: Aug 2009
MG2009 Offline OP
OP Offline

Joined: Aug 2009
Okay, Guys.

I will give this one a go:

sudo dd if=/dev/rdisk0 of=/dev/null bs=1024000 conv=noerror

. . . and let you know.

Thanks, again, for all your patience and help.

Re: Permission Repairs Error Messages
Virtual1 #32802 01/30/15 09:03 PM
Joined: Aug 2009
MG2009 Offline OP
OP Offline

Joined: Aug 2009
Hi, again.

TERMINAL SCAN ran about 1 3/4 hours :


Last login: Fri Jan 30 11:51:55 on ttys000
XXXXX-MacBook-Pro:~ XXXXX$ sudo dd if=/dev/rdisk0 of=/dev/null bs=1024000 conv=noerror
Password:
488386+1 records in
488386+1 records out
500107862016 bytes transferred in 6245.486080 secs (80075090 bytes/sec)
XXXXX-MacBook-Pro:~ XXXXX$



Anything here mean anything - good, bad or indifferent?

Re: Permission Repairs Error Messages
MG2009 #32803 01/30/15 09:20 PM
Joined: Aug 2009
Likes: 15
Online

Joined: Aug 2009
Likes: 15
It means that Disk Utility's "errors" actually were spurious. (I've never seen or heard of that before (Edit: Actually, see below.); I wonder what V1 will have to say about it.)

You're good to go! smile

Edit: I believe dd gives a block several read tries before it declares it bad, so in view of the possibility that the originally reported "bad blocks" are real, but only iffy at the moment, it's worth your while to keep an eye on things, i.e. run a scan periodically, particularly because any bad blocks that turn up will be newly developed because of the zero pass you ran a while back. This post by joemikeb explains.

Edit2: Y'know, there's one option that hasn't come up, so I'll throw it on the table: If your MBP is not critical in your life, i.e. if you can afford to be without it unexpectedly while you replace your HDD when it drops dead "out of nowhere", you can just shoot craps...get on with your life, wait for the inevitable, and deal with it when it happens.

Just back up as often as anything needs to be backed up.

Last edited by artie505; 01/31/15 03:09 AM.

The new Great Equalizer is the SEND button.

In Memory of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire
Re: Permission Repairs Error Messages
Virtual1 #32832 01/31/15 08:16 AM
Joined: Aug 2009
Likes: 15
Online

Joined: Aug 2009
Likes: 15
Originally Posted By: Virtual1
I'll make an adjustment to that. DD runs VERY slowly 512 bytes per pass. Bump that up by increasing block size. OK to use any larger number, but keep it an even multiple of 512. I use 1024000 for approximately 1mb. (performance levels off when you reach about 250k) 512 vs 1024000 can be the difference between three days and two hours.

sudo dd if=/dev/rdisk0 of=/dev/null bs=1024000

you can leave conv=noerror on there if you want it to find all the bad blocks instead of stopping at the first one. but I'm a zero-tolerance-policy on io errors. One sends it to my trashcan or RMA box.

sudo dd if=/dev/rdisk0 of=/dev/null bs=1024000 conv=noerror

(you also correctly chose rdisk. some people use disk instead, and for some reason no one can explain, DD accesses character devices much faster than block devices).

I had actually already posted your command, and a similar explanation, in the post immediately above yours (#32781), and the reason I used "rdisk" rather than "disk" is because of your post #7304 here.

I agree with you about zero tolerance and "conv=noerror" except for the morbid curiosity factor tongue

(Aside: I've often wondered how much time you could save yourself by reading to the bottom of threads. You very often post about things that have already been dealt with.)

Edit: By the way, thanks for another great post.

Last edited by artie505; 01/31/15 08:53 AM.

The new Great Equalizer is the SEND button.

In Memory of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire
Re: Permission Repairs Error Messages
artie505 #32847 01/31/15 10:28 PM
Joined: Aug 2009
Offline

Joined: Aug 2009
Let's be clear about what's happening.

dd (short for duplicate data) is just a copy command. It's similar to cat, except that instead of copying a byte at a time (relying on the underlying I/O system to use a more reasonable block size when appropriate), it copies blocks made up of records. The command was originally envisioned for copying from one magnetic tape to another, possibly changing the blocking factor along the way.

Disks have sectors, typically 512 bytes, but you can actually read across sector boundaries with impunity. That lets you, for example, write a disk file a sector at a time and then read it back 17 sectors at a time. Magnetic tape doesn't work that way. You can write blocks of any size, even as small as a single byte, but you must read them back exactly as you wrote them. If you are writing punched card images to tape, they would be 80-byte records, but you might write them in 20-record blocks. If the next program to read the tape cannot handle blocks bigger than 1200 bytes (15 records at 80 bytes per), you'd need to re-block the tape. Or if you want to copy those 80-byte records to disk, expanding each record to 96 bytes by appending 16 nulls, because the next program expects 96-byte records, that would be another kind of re-blocking. Either way, dd to the rescue. Copying data from one device (or file) to another, possibly changing record size and/or blocking factor along the way, is what dd does.

What dd does not do is look for or correct errors. It assumes it will be able to read and write the devices. The underlying I/O system will let it know if that assumption should turn out to have been overly optimistic.

So, what happens if, as in this case, you're using dd to copy from a disk device to /dev/null, without re-blocking? /dev/null is always writeable, and will never report a write error. Reading from disk, on the other hand, is more nuanced.

When dd reads from disk, the controller on the disk attempts to read however many sectors are requested (breaking the request down at track boundaries, and often rounding up each part to a full track, in anticipation that if you want anything in a track you'll probably want something else in the track soon). Then it applies error correction.

Error correction? Why, certainly. Although we think of data on disk as being digital, the signal coming from the read head is actually analog, and has to be digitized. The digital result is exact, but the analog input is anything but. Every time you read the same sector, you will see a different analog signal. Ideally, these analog signals all digitize the same, but not always. Fortunately, an obscene number of parity bits are added to the data as it's written, and in most cases errors can be corrected simply by examining the parity bits.

Disk errors are extremely common. Typical figures (from a few decades ago, when I last looked into the matter) are that you'll get on the order of one read error on every million reads, even if the disk is perfectly healthy. Error correction, relying on the parity bits, fixes most of these errors, bringing the error rate down to something like one in a trillion, even on a healthy disk. (I don't know what modern error rates are, but the push to greater and greater densities means drives are always designed to push their limits. The spurious error rate is not likely to be any better, and may be much worse, with modern technology.)

If the drive's controller cannot reconcile the error even considering the parity bits, it'll re-read the sector. The new analog signal may digitize to something it can correct.

What happens next depends on how many re-tries are needed before that happens. The exact cutoff values are specific to the controller's firmware, and will vary from manufacturer to manufacture and possibly from one model to another. More retries calls for more drastic action, and possible actions in increasing levels of severity are:
  • Do nothing. You've got the correct data with no or only a few retries, so call it a glitch and ignore it.
  • Rewrite the sector. It's not just the analog read signal that can be imprecise. The write signal is also analog, and re-writing the data may magnetize the disk ever so slightly differently. To find out, try re-reading the data.
  • Look for a spare sector, write the now-correct data there, and remap this sector to that one.
  • Give up. Report a read error to whatever program was trying to read the data.
At some point along the way, S.M.A.R.T. may be notified.

Can an error go away? Certainly. If the drive gives up after 256 retries (for example), and you re-try the read again, the drive might succeed with only 103 additional retries. That lets it re-map the sector to a spare, and problem solved. The disk is probably failing, though. Even if the error goes away, the disk itself may also be going away soon.

What you're hoping will happen when you scan the disk using dd is that marginally bad sectors will be just bad enough to make the drive take action, either re-writing the sector or mapping it to a spare. dd won't see or report any errors, but the sector is now healthier. (The disk, on the other hand, may still be failing.) dd is not itself doing any of this repair. It's just giving the drive controller an opportunity to notice and hopefully address any incipient problem areas.

There are programs that do a more thorough scan. It's possible to talk to the firmware on the drive, telling it "for the time being, do not attempt any error recovery at all. Read the sector once, and show me all the data, including the parity bits." That lets the program apply its own policy for dealing with transient (or permanent) errors.

Absent such a program, though, dd is a reasonably good poor man's substitute. It won't do as thorough a job as a real disk scan utility, but it might still be helpful.

Re: Permission Repairs Error Messages
ganbustein #32873 02/01/15 06:02 PM
Joined: Aug 2009
Offline

Joined: Aug 2009
How old is the disk, btw? My experience is 3-4 years is about as much as you get from the HDD a Mac shipped with. Was there another problem that prompted you to use Disk Utility to solve?

PS: I agree to swap it out in any case. Even 1 TB HDDs are very cheap these days.

Last edited by slolerner; 02/01/15 06:05 PM. Reason: more
Re: Permission Repairs Error Messages
ganbustein #32912 02/03/15 08:46 AM
Joined: Aug 2009
Likes: 15
Online

Joined: Aug 2009
Likes: 15
Great post! Thanks!!! smile

Originally Posted By: ganbustein
Can an error go away? Certainly. If the drive gives up after 256 retries (for example), and you re-try the read again, the drive might succeed with only 103 additional retries. That lets it re-map the sector to a spare, and problem solved. The disk is probably failing, though. Even if the error goes away, the disk itself may also be going away soon.

That sounds like it confirms my guess about why Disk Utility returned I/O errors on its first pass, but not its second second, as well as my admonition to not let the errors slide.

Originally Posted By: ganbustein
Absent such a program, though, dd is a reasonably good poor man's substitute. It won't do as thorough a job as a real disk scan utility, but it might still be helpful.

Since dd comes up only in instances when a poster either can't, won't, or hasn't yet bothered to opt for a more robust solution, your characterization of it as "a [reasonably good] poor man's substitute" is more than on the mark, because it does error correction as well as scan.

On the other hand, though, in view of "Even if the error goes away, the disk itself may also be going away soon.", dd may actually surpass its costlier brethren in that its less robust error-correction functionality is less likely to lull a user into a false sense of security.

Last edited by artie505; 02/03/15 10:26 AM. Reason: Cleanup

The new Great Equalizer is the SEND button.

In Memory of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire
Re: Permission Repairs Error Messages
artie505 #32918 02/03/15 03:32 PM
Joined: Aug 2009
Offline

Joined: Aug 2009
Originally Posted By: artie505
(Aside: I've often wondered how much time you could save yourself by reading to the bottom of threads. You very often post about things that have already been dealt with.)


sorry, my time here is very limited and my attention is mostly focused in other directions. Better for it to get said twice than not at all.


I work for the Department of Redundancy Department
Re: Permission Repairs Error Messages
Virtual1 #32928 02/03/15 08:20 PM
Joined: Aug 2009
Likes: 15
Online

Joined: Aug 2009
Likes: 15
Well said! smile

Edit: And no apologies necessary, of course.

Last edited by artie505; 02/03/15 08:21 PM.

The new Great Equalizer is the SEND button.

In Memory of Harv: Those who can make you believe absurdities can make you commit atrocities. ~Voltaire

Moderated by  alternaut, dkmarsh, joemikeb 

Link Copied to Clipboard
Powered by UBB.threads™ PHP Forum Software 7.7.4
(Release build 20200307)
Responsive Width:

PHP: 7.4.33 Page Time: 0.041s Queries: 60 (0.027s) Memory: 0.8454 MB (Peak: 1.6922 MB) Data Comp: Zlib Server Time: 2024-03-29 14:45:27 UTC
Valid HTML 5 and Valid CSS