I was using Android Studio, latest release yesterday when my PC decided to just turn off(Turns out PSU's dont last forever). I took the HDD out until I can find a replacement PSU and put it into another PC, upon opening my project I can open the MainAcivity anymore with Android Studio. I opened the Java file with a text editor and it comes up with about 8000 lines of 0's.
Does anyone know how to fix this as I put alot of work and time into that file?
Your file is corrupted, the sector of the disk where the file is stored is effectively damaged / unallocated because the file was being held in the disk cache / currently written.
Resetting the file from version control
If you use a version control mechanism such as git, mercurial or cvs, you can try check-out the file from the system from the moment of your latest successful check-in. If that fails you can try cloning/checkout out the online version of your repository and see if that is the correct version to.
Recovering the file from backups
Every person SHOULD have a proper backup system, making backups is relatively easy to do, and even a git repository stored on multiple computers can already be a good backup.
Even Jeff Atwood has made this mistake in the past. (yes, he is user 1)
Recovering the file using disk checking applications
Sometimes, you may have more luck using chkdsk on Windows or fsck on Linux.
This may happen because you worked on the file, and the file system decided to move the file to another sector for various reasons. Then, while it was moving the file, the hard disk crashed. This left the file pointer referring to the new location, while the file is still safe at the old location.
On Linux and Mac, files recovered by this technique are stored in directory /lost+found, while on Windows, this directory is called "/Found" located in the affected hard drive.
Decompiling your old application
Sometimes, the above techniques are delivering anything resembling your original code. In this case we need to use our must ugly method, decompiling.
There are various java and android decompilers you can use, these can be easily found on google by searching for "java decompiler". I am not going to name them here to prevent this answer from becoming opinium based on what decompiler is the best.
Related
I am maintaining a Spring Boot project. There is this code:
BufferedReader reader = new BufferedReader(new FileReader("./setting_mail_sender.txt"));
Where should the file be located in this case?
In 'the current working directory'. And where is that? Who knows!
Whomever wrote that code messed up. It's not a good idea to use the CWD for anything in any java code unless you specifically know you want it. And generally, that's only the case when you're writing command line tools in the vein of the various tools you find in your average linux distro's /bin dir - a rare occurrence, given that the JVM isn't really designed for that kind of thing.
There are 3 different best practices for 'data files' depending on the nature of the data:
Static, unchanging data - as much part of your app as your class files are. These should be loaded with MyClass.class.getResource("name-of-resource.txt") and shipped the same way your classes are. For example, inside the jar file.
Config files. These should usually be in System.getProperty("user.home") - the user's home dir; /Users/yourusername on macs, /home/yourusername on linux, C:\Users\YourUserName on windows. Best practice is to ship a 'template' version of the settings file if relevant in the jar file, and upon detecting that there is no config file present at all, to write out the template (and you load the template in via MyClass.class.getResource). If a template is not a good idea, something in a similar vein. Bad practice is to have the installer do this, and have your app be broken or leave the user having to peruse complex documentation to (re)create the config file. A different way to do it right is to have a config page in your app (a window, menu bar setting, web app thing - something with a user interface) where you can change settings and the config file is simply the way you store that data.
Changing data files. For example, you ship H2 (an all-java database engine) with your app and it needs to write its database file somewhere. This is a bit tricky; user home is not the right place for such data files, but you can't really 'find' the dir where your app is installed either. Even if you can, on non-badly-designed OSes, apps usually cannot (and should not!) be able to write to that location anyway. The location where this data is stored should definitely be configurable, so one easy way out is to require that the user explicitly picks a place. Otherwise I'm afraid you're stuck having to write per-OS code - find /Users/myusername/Library/Application Support/yourappname on mac, which is the right place. As far as I know there is no library to do this right.
None of them involve 'require that the user start the app with the right CWD'. There are good reasons for that: It can be hard to configure, and it's not something users think of to configure. For example, when setting up a java app as a recurring task in windows, you can configure the working dir for such a process, but it's not something that's usually considered as crucial configuration. When running a java app from the command line, who knows what the working dir is. You'll end up with an app that usually works, except in some circumstances when it magically doesn't, and most of your users have no idea that the difference between the magic run that works and the one that does not, is the directory they were in when they started the java app.
If you can edit that code, do so - figure out which of the 3 different kinds of data this is about (sounds like the second bullet: Config stuff, so should be in user home, and the app's name should be part of the file name) - and fix it. for example, that should be:
try (var in = Files.newBufferedReader(Paths.get(System.getProperty("user.home"), "myapp-mail.conf")) {
}
This solves a whole bunch of problems:
Uses try-with to avoid resource leakage.
Reads from user.home, avoiding current working directory as relevant setting.
Actually uses UTF-8 encoding (whereas your code will, at least until java 17, do 'platform default'. It's somewhat unlikely you want that, as it means your config file is not portable; copying it from one computer to another may break things. You presumably don't want this.
If errors occur, the error messages are improved (one of the downsides of the 'old' file API).
If you can't change this code, figure out what the CWD is; put the files there, and ensure that, however you start this spring boot project, you always start it from that directory. If you can't change this code but you can run some code in that JVM, you can print it: System.out.println(Paths.get(".").toAbsolutePath()) will show it to you.
LibGDX: I have game-data files created at runtime for debugging purposes (a replay system). The files are stored in Gdx.files.local() whether on desktop or android. Now I want to copy the ones that were created on android so I can debug them on desktop.
Running Gdx.files.getLocalStoragePath() on android returns /data/user/0/com.[my domain].[my app]/files/. Using Windows Explorer I do not see my app's folder in /data/user/0, or anything else for that matter. So private storage indeed it is, but how nonetheless can I get hold of these files, without root if possible?
The solution may be manual copy or in code, whatever works. Just to note, the file names are unknown without seeing the files first. They were named using current date-time. The extension is known, though.
EDIT
I discovered Android Studio's Device File Explorer. I connected my device, tried to see inside my app folder and app data folder, both showing 'Operation not permitted'.
So to put the question in simpler words, is rooting the phone really the only way for developers to see the files created by their apps?
Or is there a magical gate somewhere known only to select few zen masters who guard the secret through the generations? Because I sure ain't finding it.
I'm not sure that there is a way to write changes in the system file without having root access but you can read them. According to this Blog, You can access those files and put it in your desktop. You can download RAR app from googleplay.
I'm making a game, in Java, that has these following important features:
1) Connects to a remote Server (which i made), and will check for updates and install them if necessary
2) is NOT A SINGLE .JAR FILE (ie. has multiple .jar's and other things, such as .png, .wav, etc)
3) JAVA WEB START IS NOT AN OPTION, AS I WANT TO MAKE THIS ALL MYSELF
keeping the things above in mind, i have run into a problem. i have no clue how to implement a multiple "patch" update system. currently i have 1 .txt file, that the server reads from, and sends the files listed in the .txt to the client, which then moves them into place. The problem is, that is only useful for maybe 2 updates. I'm looking for a more useful, long term solution, and i need some help. here are some of the things i've thought of:
1) have a zip folder named after each version (problem: how would the client get ALL of the most updated files
2) have a .txt file INSIDE of each jar containing the version (problem: cant do that with png's or wav's, and i dont know how i would read the txt file to begin with)
i really need some help, i've tried googling it, i've thought about it for going on 3 weeks now, and cannot think of anything.
QUESTION: how would i make a game/program update with multiple patches?
Firstly, the best solution by a long, long way is to use Webstart / JNLP.
But if you insist on not using it (for whatever reason then) then it is technically possible. However:
It is messy and complicated.
It will either be very inefficient ('cos you have to load the entire program each time the user), or the user has to trust you enough to install your program with permissions that will allow it to install random stuff on his machine without notice.
The way to do it is to split the game into a launcher part and an application part. The launcher needs permissions to write and delete (non-temporary) files, and fetch stuff from the internet. It "calls home" to find out the latest version(s) of the application files, and then downloads and installs them. It has to cope with all sorts of error conditions, and it needs to make sure that nothing can trick it into installing bad stuff on the user's machine, etcetera, is someone spoofs your update service.
Of course, JNLP takes care of all of this, and lots more besides. People are going to be more willing to install the JNLP infrastructure that yours ... which might be insecure, or actively nasty (for all they know). (I for one wouldn't install a self updating application on my machine unless it was supplied by a company with impeccable credentials.)
I think you need here JNLP framework.
JNLP provides followed things:
allows to user to download jars from server
on launch verifies if application need to update
runs on local JVM
Actually, every java application you can convert to JNLP. Just to sign on all jars that your game contains, create executable jar from your game and create single Web page from where you can download your game
I have a strange problem. When I try to delete a file created by my application it gets deleted and gets replaced with a junk file of the exact same filesize. Can someone please help me out with this? Beats me. The same thing happens when I try to delete the file manually.
are you perhaps using an NFS file system on linux? NFS will leave tombstones behind deleted files in some cases.
(Unless you specify your operating system and post some of your code, this is pure guesswork.)
Since deleting the same file manually causes the same behaviour, it's reasonable to assume that this is not an issue with your code specifically.
Some filesystems (FUSE on Linux comes to mind, as well as some network filesystems) present this behaviour when deleting files that are in use by another process.
I use Eclipse to write Java code and use DropBox to sync my code with others' across our multiple computers. Most of the time, everything works as expected: if anyone makes a change on either end, the change is saved and when the other person refreshes the Eclipse workspace, the changes come through and can be viewed and run successfully.
Sometimes, one of several errors arises. Sometimes Eclipse says it cannot find a main class and sometimes it says it could not find the class itself. Sometimes it will not report an error but for some reason will not actually update the .class file and therefore run an old version even though the compiler displays the new source code and that saves. I've then noticed that if I manually copy the code into a new .java file elsewhere in the file system and then compile it, it works fine, but for some reason it refuses to regenerate the .class file and I have to delete it manually and replace it with the one generated in the other project--then it works. But for solving the other problems everything needs to be manually copied, deleted, and re-pasted....
[The actual errors include NoClassDefFoundError, UnsupportedClassVersionError, and some other error related to not having a main class.]
I realize that the description here is somewhat vague, but unfortunately I'm not entirely sure what's going on. I hope I'm just missing some basic fact that would help solve all these problems.
Thanks!
I'm sure you will see issues using Dropbox for sharing your source.
Eclipse does not know what Dropbox is doing whilst it's uploading and downloading updates and their activities will certainly not be synchronised. At arbitrary points in time when Eclipse tries to do builds etc. it will find unexpected activity going on, maybe even partially downloaded source files which might explain the specific errors you are seeing.
You're trying to do something more complex than sharing photos or documents. The advice I would give is to use a source control system like git or subversion for source code sharing and control. You can then make use of plugins for Eclipse that are designed to integrate these systems in an easy to use way. There's a learning curve there, but the skills will serve you well.
You can use online versions of these solutions like github and unfuddle if you want to consume sharing, backup and version control of source as a service like you do with Dropbox. They're free, too.
Subversion, Git and all version control software solve all of these problems for you.
Dropbox is not really an adapted system for sharing code. What you should do is set up a SVN, and commit only the source files. This way, you won't have these kind of errors.
Dropbox does have versioning (you can restore old versions of a file), and doesn't seem to be a horrible solution for the problem. I keep my Eclipse repository on Dropbox so it is available on any computer; but since I only use it myself, I haven't encountered your problems.
There is one case I can absolutely see you running into problems--it's if your class files are stored in the dropbox as well. This would just screw everything up. Make sure you specify a location on your local hard-drive for all build artifacts (classes, jars, ...) and that the only thing on your dropbox is the .java sources.
In fact, I suggest you don't keep your eclipse project in your dropbox, just create your eclipse project and point it to the java files in your dropbox.
If this doesn't work for you, go with what other people here said and set up a SVN repository somewhere, it's easier than you would think.
Oh, another possible problem--dates! You may want to make sure the date on your java files isn't jumping forwards and backwards (as might happen if one of your developers were in another time zone). In this case, Eclipse may prefer not to re-compile your file.
Also, instead of the copy/etc procedure you are currently going through, try forcing a project clean.
Response to request for more info:
When you start Eclipse, select/create a workspace that is NOT on your dropbox. The best place is probably off your home directory. If you have already specified a default workspace, there should be a switch workspace item in the file menu.
Create your project. select "Create project from existing source" and specify the source files in your dropbox. I think you want "create separate folders for source and class files" to keep your class files out of your dropbox. If you see anything saying "Copy files into your workspace, say "no".
This should give you a valid, working project. I hope you don't see those problems any more.
One more thing may help--and this may work on your existing project--without the above procedure...
Whenever you refresh your files (f5) to load in changes from the dropbox, select the Project/clean menu and select the project. This should delete all the class files and rebuild them.
If your classfiles are shared on the dropbox, this could still have strange consequences on other people with eclipse open, so I really do suggest rebuilding your workspace as I said above.
How to avoid no main class
Provide one. That issue has nothing to do with DropBox