Minecraft, java version, the view rotates 180 degrees and looks at the ground randomly and the game or PC crashes - The Fix!

I wasted a lot of time trying to find out why the latest (Java) Minecraft versions are buggy. The view would spin 180 degrees so I would facing the other way and to add insult to injury, I would also be looking at my feet. In the middle of a mob battle or walking a cliff, this is not fun.
Additionally Minecraft would lock up and sometimes lock up the whole PC.

I thought from many, many posts I'd read that it may have been:
1) another mouse-using program such as Synergy,
2) my Java version (ie. must be Oracle java and not Openjdk),
3) graphics card drivers.

As it turns out it was Minecraft itself. I rolled it back to version 1.12 and it works like a charm. Sure, I lose some of the latest mobs, etc. but I don't care.
I'd rather a stable Minecraft than a fancy but buggy one. I play to relax so crashing my game/PC is not cool.

I wonder if Microsoft are doing this to push people away from Java Minecraft to Windows/Xbox Minecraft? It's been happening for a long time and yet no fix? Hmmm...

Fixing a read only USB drive

I discovered that putting a USB drive into my Linux Mint PC resulted in it being read-only. After a little bit of googling I discovered a simple fix. It turned out that a minor corruption was the culprit.

First login as root:
$ sudo su -
<enter root password>

Find the drive with:
$ df -Th

In my case it was: /media/martin/735F-4AA5 and also note where it is mounted, in my case /dev/sdd1 

So unmount it:
$ umount /media/martin/735F-4AA5

Find and fix any corruption: 
$ dosfsck -a /dev/sdd1 


Open the folder and look for a file starting with FSCK and ending with .REC.
Hint: It's likely called FSCK0000.REC
Now delete (move to trash) the file and then mount the drive and all should be good.

Simple :-)

Find and optionally delete empty folders and files under Linux

To find all zero size files, simply use:

find ./ -type f -size 0

or:

find ./ -type f -empty

This commands will find all zero size files in the current directory with subdirectories and then print the full pathname for each file to the screen.

• The ./ means start searching from the current directory. If you want to find files from another directory then replace the ./ with the path to needed directory. For example, to search everything under the system log directory you need to replace ./ with /var/log.
• The -type f flag is specifies to find only files.
• The -size 0 and -empty flags is specifies to find zero length files.

To find and then delete all zero size files, there are variants you can use:

find ./ -type f -size 0 -exec rm -f {} \;

find ./ -type f -size 0 | xargs rm -f

find ./ -type f -size 0 -delete

The xargs will cause all the filenames to be sent as arguments to the rm -f commands. This will save processes that are forked everytime -exec rm -f is run. But is fails with spaces etc in file names.
The -delete is the best when it is supported by the find you are using (because it avoids the overhead of executing the rm command by doing the unlink() call inside find().

Empty directories

To find all empty directories, simply use:

find ./ -type d -empty

This command will find all empty directories in the current directory with subdirectories and then print the full pathname for each empty directory to the screen.

• The ./ means start searching from the current directory. If you want to find files from another directory then replace the ./ with the path to needed directory. For example, to search everything under the system log directory you need to replace ./ with /var/log.
• The -type d flag is specifies to find only directories.
• The -empty flag is specifies to find empty directories.

To find and then delete all empty directories, use:

find ./ -depth -type d -empty -exec rmdir {} \;

or:

find ./ -type d -empty -delete

The -delete is the best when it is supported by the find you are using.

Simple synchronising and back up of two folders for Linux

To simply synchronise / back up two folders I use rsync.
I have several folders on two different networked devices (NAS's) I want to keep in sync.
I use a script to this. I could automate this but I like to see the magic happen. Maybe I'll automate this later with a cron job but for now:
I log into one of the NASs using SSH.
Note: I have setup public and private certificates so I don't need to enter passwords. I'll leave that as an exercise for the user.

$ ssh aUser@192.168.0.3

then I run my script on that box:

remotebox:~# sh syncFiles.sh

The contents of this script is as follows:
rsync -avP --delete aUser@192.168.0.4:Shares/Public/movies/ /mnt/HD/HD_a2/movies/
rsync -avP --delete aUser@192.168.0.4:Shares/Public/music/ /mnt/HD/HD_a2/music/
rsync -avP --delete aUser@192.168.0.4:Shares/Public/pictures/ /mnt/HD/HD_a2/pictures/

As you can see from above I backup movies, pictures and music from 3 folders.

The syntax is as follows:
rsync <parameters> <source> <destination>

The parameters are:
 -a means "all" files/folders,

-v means "verbose" so we can see what is happening,
-P means show a progress bar,
--delete means if something is deleted from the source, delete it from the destination. This is great for synchronisation but maybe not what you want for your backup? Use with caution. If in doubt, don't use it initially.
<source> of course is what to copy and
<destination> is where to put it.

Speed up network file transfers

So I was trying to transfer 38gig of small files using Samba from one PC to another PC and it started by announcing an hour and a half to do it.


Half an hour later this had grown to 7 hours.  WT? That's "Windows-time". hehe.

After some research I discovered that the using the Caja file manager in Mint 18 to browse and copy over Samba was the issue.

The solution was simply to mount the drive first outside of Caja.

Note: I did read that different Samba versions can be a cause too though I didn't bother with testing that. Maybe it would be faster but I'm happy enough to let it go at an hour and half. I have a life outside of PCs after all, lol.

Note 2: If you're on Mint with the Mate desktop, you may need to install Caja-share via the Synaptic Package Manager.

Anyway, to temporarily mount the drive I used:
$ sudo mount -t cifs //192.168.3.1/games /media/myshare/games -o guest,uid=1000,vers=2.1

Note: Playing with the last option (change 2.1 to 2.0) may improve speeds.

Good luck

Update:
The transfer slowed down again. I'm guessing partly because of there being too many small files. That got me top thinking about creating one compressed file as that would transfer quicker then many small files.
After some reading I came across this idea. Compress the files over a network directly to the target machine. This cuts out the writing of the compressed file locally.

To do where security doesn't matter I used netcat + tar:
To send a directory, cd to inside the directory whose contents you want to send on the computer doing the sending and do:
tar -cz . | nc -q 10 -l -p 45454
On the computer receiving the contents, cd to where you want the contents to appear and do:
nc -w 10 $REMOTE_HOST 45454 | tar -xz

The disadvantage is you don't get any feedback on progress. I use a network graph so can see data being transferred but that's it.

A quick fix for disk space issues by removing old kernels

One way to quickly get some free disk space is to remove old kernels.
To do this you'll need Byobu. This handy app will remove all old kernels except the current and last 2. Why this isn't automatically done by Linux I don't know?

Anyway, install Byobu with this command:
$ sudo apt-get install byobu

Then run it:

$ sudo purge-old-kernels

Too easy :-)