Bug: Making the properties, history, and possibly the log files hidden makes them innaccessible to RipMe

I just recently figured this one out. It seems like if you make history.json, rip.properties, and possibly ripme.txt hidden in Windows, RipMe cannot access the files. While it will still read the settings saved in rip.properties, it cannot modify them. Any changes in settings you make while that file is set to hidden will be undone when the program is closed. History does not save when history.json is hidden. When you look at the logs, it will mention a file access error:

java.io.FileNotFoundException: history.json (Access is denied)

and

2015-06-25 20:57:07,833 ERROR utils.Utils .saveConfig() Error while saving configuration: org.apache.commons.configuration.ConfigurationException: Unable to save to file C:\Users\Folder Path\rip.properties

I’m pretty sure the log file doesn’t update as well if it is hidden, but I haven’t thoroughly tested that out.

[drguildo]

Just disconnect it and it’ll never wear out.

[metaprime]

I agree the pattern you mentioned should be avoided, but concerns like tiny writes to the file system on the part of this program is not really part of the concern. The OS and other programs do plenty of that on their own, and probably in much greater quantity than we could expect ripme to do. Not to mention, the whole purpose of this program is to save lots of data to your file system. That’s going to be way more “harmful” for the SSDs than little writes. No sense in worrying about that kind of optimization for small files.

I’d say the problem here is just that these files shouldn’t be made hidden in the first place. Whatever mechanism made them hidden – well, don’t do that. That’s why I closed as wontfix.

I suppose if we could detect that a file was hidden, we could give a more helpful warning, but Java might prevent us from even knowing the hidden file is there at all.

Anyway I’m not sure the unhide/write/hide problem is really a problem for SSDs or any modern file system or storage device. SSD drivers are smart, and good at aggressively avoiding harmful writes when possible – when a change to a file is saved (the file system is updated) it doesn’t necessarily mean the change has been written to the physical disk in the sense you’re probably thinking. The change could still reside in RAM until a certain time passes where the changes are committed to disk. (This avoids problems for the hard disk in the case of the supposed anti-pattern of repeatedly saving a file with only minor changes each time – wouldn’t you just want to REALLY save the version that was there when the user or program stopped accessing the file entirely?) I’m not that sure how a file system journal works with the specific limitations of SSD wear patterns, but there may also be a journal updated with the changes to a file which can be replayed until such time that it makes sense to really re-write the file to a new place on disk. Appending to the same sector in a journal is a good pattern for SSDs.

Reading data from the file is a basic requirement, nothing to fix there. Also if reads are “bad” for the SSD in the sense that it wears down the drive, then sure, but a read is a basic need and is definitely the LEAST bad for an SSD. Long story short: use the device as intended. Don’t worry too much about the consequences of small anti-patterns.

If we were frequently making tiny updates to a whole LOT of files, then we’d have something to potentially worry about.