If I write a program that simply opens a text file, reads an integer from it, writes a new random new integer, and then closes the file, and I put this inside a "for" loop set for next month, will it "burn a hole" in my HDD or cause any other unfavorable scenario?

 

No not all by itself. The number one failure mechanism is contamination of the sealed chamber. A little flake of anything breaks away, causes a head crash, and it is downhill from there.

 

HDD drives have a no theoretical limit to the number of writes. If you were writing to the same spot over and over, even mechanical wear would be limited (no head movement required). So it would appear as if it would last 3-7 years.

SDD drives are different. They can only support 10,000 writes of a bit, before they fail.

 

The claimed read/writes are highly variable. That said, I had a SSD (Sandisk) brick on me in late January this year. It was replaced under warranty, but I would have much preferred the data. I lost all of my e-mails from the kids/grandkids and some desktop stuff in folders, including PCB designs. The only thing on my desktop now are shortcuts to my RAID1 HDD's and WLM e-mails. I am looking for a simple way to keep e-mail (WLM) backed up on the HDD's.

John

 

I am looking for a simple way to keep e-mail (WLM) backed up on the HDD's.

I run my own email server. I connect to it via IMAP. All email resides on the server, not on any of my multiple email clients, and all emails are accessible via any client. The server is backed up regularly.

You may not have the ability or desire to run your own server. But there are multiple email services that support IMAP. Think about it.

 

I run my own email server. I connect to it via IMAP. All email resides on the server, not on any of my multiple email clients, and all emails are accessible via any client. The server is backed up regularly.

You may not have the ability or desire to run your own server. But there are multiple email services that support IMAP. Think about it.

I tried setting up an email server. Spent me a good while banging my head against a wall before i figured out that my ISP was blocking my ports. Apparently they don't want me being the master of my own email because if i were to set up a spamming operation, it would get them and their other customers blacklisted. Somehow in the process, I managed to get my own domain blacklisted on several reporting sites, even though i never successfully sent or received an email.

My research suggested that my options were:
1. Pay for business class internet, twice as much per month for the same speed.
2. Use a paid port relay service. For the same price or less, i can get external email server hosting.
3. Call comcast and request they unblock my ports, which they may or may not do, and i would have to call them each time my router rebooted.

I opted for external hosting

 

HDD drives have a no theoretical limit to the number of writes. If you were writing to the same spot over and over, even mechanical wear would be limited (no head movement required). So it would appear as if it would last 3-7 years.

SDD drives are different. They can only support 10,000 writes of a bit, before they fail.

That is contrary to what I thought I knew. Maybe I just assumed it, but I thought I read somewhere and made an informed decision to upgrade to SSD and my data would be secure potentially forever, barring damage from water, fire, or virus. Thanks for bringing this to my attention. I will make sure to increase the frequency of my backups.

 

If I write a program that simply opens a text file, reads an integer from it, writes a new random new integer, and then closes the file, and I put this inside a "for" loop set for next month, will it "burn a hole" in my HDD or cause any other unfavorable scenario?

Are you saying the 'for' loop executes once a month? In that case, you might cause a failure in 10,000 years.

 

Are you saying the 'for' loop executes once a month? In that case, you might cause a failure in 10,000 years.

No, a continuous loop. Say it reads & writes to the same location every 1mS for a whole month.

 

I wondered about the same thing, because my home-brew light controller needs to continually open a file to examine it for the presense of a command. So, I'm opening the same file 100's of times each day. However, I can avoid all of that by reading a named pipe (fifo) instead. And that's how I'm going to handle it.

 

I wondered about the same thing, because my home-brew light controller needs to continually open a file to examine it for the presense of a command. So, I'm opening the same file 100's of times each day. However, I can avoid all of that by reading a named pipe (fifo) instead. And that's how I'm going to handle it.

yes I found a similar solution. In Python I was considering using the mmap. It creates/loads/saves files in RAM as if it were in the HDD. Considering RAM is meant to be continuously overwritten, I assumed this would be a much safer solution.

But my need for this has expired. I found another way that does not require any kind of solution like this. I was dealing with a python script that gets killed and executed anew every 24mS, and I needed values from the current instance of the script to make it into the next instance. I simply created a second script ("database" script) which runs in the background and has a class\object that holds a dictionary. The "every_24mS" script calls the object in the database script containing the library, reads from it, writes to it, and then commits suicide, and NEXT. I assume this happens in RAM by default and not in the filesystem; that would just be silly.

 

I don't really understand the dictionary, but good to hear you have a solution. BTW, I finally implemented my solution to this problem last night. It is simple, though just a little tricky to implement, and just different enough from how it worked on the UNIX system I last tired it on to trip me up for a little bit. But it works great! If you want more details, I'll happily provide them. I'm going to update my thread on the subject with the details shortly.