I am getting the warning
Warning: sendmailpm.jsp modified in the future.
What does this mean?
You aren't allowed to modify anything in the past if doing so might change the future. You might cause a temporal paradox, which could corrupt the time stream and cause our entire reality to cease to exist.
Please do not modify that file.
JSP files are compiled. Many servers also allow you to replace the files on a running server. It then compares the timestamp of the compiled source and the timestamp of the jsp file to determine if it needs to recompile.
If the file is dated in the future, the jsp file will always be newer than the class. This gives you a warning.
Check the timestamp on the file. Perhaps someone created it on a computer with an incorrect clock, and now it appears to be "created in the future". Or perhaps the server has the incorrect date (check timezone settings).
Are there remote file servers involved? Clock drift between a web server and a file server can cause this error too.
To diagnose this further, you'd have to give us some hints - what jsp server, what OS, what filesystem?
During an Ant build, this warning can be output during a task.
[copy] Warning: foo\bar.txt modified in the future.
Ant's <copy> task by default won't copy files if the destination files are newer than the source. This saves much time and disk I/O. However you can override this behavior with the option <copy overwrite="true">. This tells Ant that you know what you're doing; overwrite the destination files regardless of their modification date. This will also suppress the warning.
If your code is residing on a FAT/FAT32 partition or ZIP file, this can be caused by the lack of precision in the FAT/ZIP filesystem's timestamping, which is 2 seconds (afaik). This can cause compiler / build tool output to be saved with a time slightly in the future, so that when the next build/deployment step (can be internal to a JSP container) is executed, the file will appear to be from the future and the warning is produced. Try using a different file system, e.g. NTFS on DOS/Windows boxes.
I had the same warning message from Apache Ant when trying to do a Java build on a FAT32 TrueCrypt partition. After ruling out other causes (timezone difference, clock off etc), I eventually found a hint on this, changed to an NTFS TrueCrypt partition and the warning disappeared.
Someone probably modified the file, then changed the time on the server. Try checking to see what time your box is set to and make sure it's correct. If it is, you can probably ignore that warning without any side effects.
Check whether system time is correct or not. If not sync it with Standard time for your zone. Then run your build file.
JSPs are compiled on-the-fly to servlets. The servlet container compares the "last modified" dates of both to see if the JSP has been changed and the servlet needs to be updated. A "last modified" date in the future indicates that something is wrong with the system clock, which is relevant because it could disrupt the abovementioned mechanism, leading to servlets that are not updated.
This is because, The time of the system is not current on which you are running the build file
If the java file that you are compiling has a time stamp that is beyond the current time of the system on which you are compiling...you will see this warning.
I modified the file on one machine and put it on another and tried compiling and came across this issue.
I got the same issue. The solution was: I changed the date and time on the build machine, so that it was in sync with the date and time on machine which the files were copied to.
If you have a jar file that you are trying to install at remote server. It might happen that remote server timestamp is not matching with your time zone. If your timezone is couple of hour ahead than the remote server then you might get this issue.
I also tried out one more trick..
When you create a JAR file, then go to system time and set a date couple of months back and try installing the JAR, you get this error.
I had this error too, but after reading some answers above i realized that is was due to the change i've done in the computer to some days ahead because of the test of a functionality that requires date manipulation.
Here is what happened:
1 - To perform Unit Test of a new implemented functionality i had to set the computer date to 4 days in the future.
2 - When i performed the test the compiler compiled the class automatically, as expected.
3 - Therefore when i was trying to rebuild the project the IDE detected that the file was (ironically) created in the future. (LoL - that's why i love Java you can even code in the future.).
So +1 #jmanning2k.
I hope it can help somebody facing this issue.
That warning appear to me too, it was because a previously changed the time in my computer to fix it because it was like 20 minutes ahead of the actual time
Related
I hope you're doing well in these complicated times, good containment all around :D
So I come to my problem, currently I'm working on a game in Java and I know that it's possible to modify the jar file of my game which annoys me a little bit because it can give cheating possibilities for malicious players... I had thought of a solution even if it's not infallible, it would be to make sure to check if the jar file has not been modified. But the problem is that I don't know how to check this, I had thought of a system that would check the point of the file even if I doubt it would be the best solution.
If you have any other ideas to secure my game I would be interested :D
It is possible to check if a JAR file on your machine has been modified. Simply compare a cryptographic hash of the current JAR file with a previously recorded hash for a pristine copy. (Or just do a byte-by-byte comparison with the pristine copy.)
But you can't do this for JAR file on the user's machine:
You can't login to the user's machine and access their file system to look at the JAR file. (Even if you could, there is no guarantee that you would see the file that the cheater is actually using.)
If your application (running on the user's machine) tries to report on the integrity of its JAR files, this can be defeated by the cheater. All they need to do is to modify the JAR file containing the reporting code to report a fake hash.
Basically, there is no reliable way to detect that a cheater is running a modified JAR ... apart from detecting the anomalous behavior of the cheat itself.
But think of it this way. If there was a good (reliable, no circumvention) mechanism for detect that a cheater is running a modified client, then cheats would not be a problem in the many online games that exist out there. And (by extension) there would be no way to defeat software license enforcement schemes ... because software vendors would use a similar mechanism.
So, my advice would be not waste too much time on this approach. It only works against people with limited technical expertise or limited motivation.
The only way to completely prevent cheats is to control the platform on which the client runs. That is usually impractical.
In regards to your question about other ideas, the best thing you can do is validate everything from the client. One thing you should always remember is that the client cannot be trusted because you cannot verify anything from it. All you can do is store the state on a remote server and when the client tells you something, validate it, and give a response if necessary or prevent the action if necessary.
You will need to somehow find out where the jar file is: Java - Search for files in a directory
Then you can check for the last modified date of the file: https://www.boraji.com/java-get-last-modified-date-of-a-file
However, I would not consider this a very powerful defense against cheating, because one can modify the jar file and remove the validation of the file date.
You will need to think about the kind of cheating that can occur and to come up with other security measures as well.
EDIT
As Dave Thompson pointed out, the modified timestamp can be changed as well, which makes the modification of the jar file unnecessary, even though reverse engineering is still needed by the hackers, because that's how they find out what the rules of the application are.
I am using Ubuntu (in case it will make a difference) and I am trying use Camel to send files to processor from one folder. But the problem is that when I am saving this file in the folder (takes about 5-10 seconds) Camel picks it up straight away.
To simulate the process I am using gedit with txt file with ~500k rows so it will take some time to save.
I have tried adding options:
from("file:src/Data/new/?readLock=changed&readLockMinAge=3m")
I have tried using
.filter(header("CamelFileLastModified").isGreaterThan(new Date(System.currentTimeMillis()-120000))) to give 2 minute delay.
Nothing seems to influence its behaviour, it picks it up straight away, throws an exception because of some checks while processing file and moves it to the Error folder.
I know there is an issue with FTP file transfers which I will have to face later on, but I can not even get it working on local file system.
Any help will be appreciated!
SOLVED
from("file:src/Data/new/?readLock=changed&readLockMinAge=3m")
Parameters actually work as they should. I was using Jetty to run the project and I should have done whole project clean/install after any amendments.
I had to amend parameters a bit to:
from("file:src/Data/new/?readLock=changed&readLockTimeout=65000&readLockMinAge=1m")
because it was complaining that readLockTimeout should be more than readLockCheckInterval + readLockMinAge.
Have a look into the documentation:
Avoid reading files currently being written by another application
Beware the JDK File IO API is a bit limited in detecting whether
another application is currently writing/copying a file. And the
implementation can be different depending on OS platform as well. This
could lead to that Camel thinks the file is not locked by another
process and start consuming it. Therefore you have to do you own
investigation what suites your environment. To help with this Camel
provides different readLock options and doneFileName option that you
can use. See also the section Consuming files from folders where
others drop files directly.
So I think the doneFileName option will solve your problem.
I'm trying to find a solution to my problem, which is only applicable in our test environments. I'm working with systems
(banking) depending on each system being on the same specific date. The development we do is solely within system integrations.
In short: Our systems generate the data, which we then adapt between our systems. Naturally, we do not hold the source
codes to the systems we have.
To my specific problem: I have a system(A) running on JBoss: JBoss_4_2_3_GA on Java JRE build 1.6.0_32-b05. I've set up
a messaging broker in WebMethods(WM) listening to a specific port on this system. When users trigger certain events in system(A), JMS
topics are created and sent to a queue. WM then do a few validations and deliver the messages to system(B).
Everything was working properly, up until recently when we noticed that system(B) was expecting a timestamp field being
on the same date as the system itself were in (the functionality we built won’t otherwise work). The problem is that system(A) does not provide such a system date option,
and the timestamp in the messages are "real" timestamps from the operating system (Windows 2008 R2). So I require
a fake date (timestamp) applied in system(A) which would be on the same date as system(B).
The first solution to this problem was simply to disable the NTP sync and set a fake timestamp in Windows running
system(A), which would solve the date issue. But doing this, we noticed that our Windows group policies stopped working,
which affected normal logins to the server. So this was not a solution we could apply.
I know that others have posted this specific issue, and solutions such as using java date alternatives as Joda-Time etc.
I don't see how I can apply mentioned changes into my system(A) due to the lack of source code.
Help/suggestions would be greatfully appreciated. Right now I’m blindly focused into changing the timestamp in Java in system(A). Perhaps there are better alternatives such as just applying the fake date in WM? I just don’t know enough about WM to do this either.
Ok, I finally found a solution to my problem. Since the lack of source code, it was really a hard shot to do anything within the application (Java/JBoss). Searching arcoss forums, I found a nifty little tool (for Windows) called "RunAsDate". This tool does exactly what I need, as it intercepts the API calls to the OS related to dates and times and gives whatever date/timestamp the user chooses!
The best thing is that it doesn't make any changes to the system (dll's), and runs either from the simple GUI (in app package) or called from command line. Of course it will take arguments if required.
I hope others can find this as helpful as I do: http://www.nirsoft.net/utils/run_as_date.html
BR
/rash
I tried to reimport my android project on eclipse to solve a problem but I accidently overwrote all my files in the project. All of them had been corrupted which means their size is now 0B...
I tried to use Local History but it's useless since my project is no longer in my workspace, same for .metadata.
I also tried to use Recuva (Software for recovering files) which see my files with their real size but when I try recover them, their size is always 0B...
I lost about 7 days of work and I don't really want to rewrite my code using Java Decompiler...
So my question is, is there any solution to recover that files ?
I wrote 200 lines of code and suddenly system restarted. I lost all code. But I recovered data from eclipse's local history. Right click on the file -->replace with-->previous from Local History
Eclipse has a local history, although by default it's set very low - one of my first tasks when setting up a new development machine is to up the values (in addition to my other version control)
If you do have a history you can right click on your class, and select compare with local history.
You could try decompiling with something like JD-GUI. It might not be as onerous as you think. Obfuscators exist for a reason.
It is not really programming question, but i had similar situation and "Mini Tool Power Data Recovery" tool helped me (it is paid tool, free version exists, but maybe you can search in this direction and find something open source). I tried some another tools then, but with no results.
As can be seen below, system time and SoapUI's time value is different.
SoapUI using JRE time and that's why it should be a bug of Java's itself because; also below code gives: Venezuela Time
String tzn = TimeZone.getDefault().getDisplayName();
System.out.println(tzn);
What I've tried and failed:
Playing with regedit and changing time zone then get it back to correct.
Giving -Duser.timezone="Europe/Istanbul" at Control Panel/Java/JRE Settings/Runtime Parameters or giving same parameter inside the JAVA_OPTS variable.
Changing time or time zone and get it back.
I checked this question surely, correcting the timezone programmatically is doable but I need to correct SoapUI's timezone which affects automated test results. Because tests are time dependent.
I really tried hard to solve this issue, for days. I really don't know why the most plausible two methods are not working properly which:
Creating JAVA_OPTS system variable which has the value of: -Duser.timezone="Turkey"
Passing vm parameter from command line.
At last I gave up and set this parameter for each specific program, to be able to do this for SoapUI, go to SoapUI Home Path/bin folder and right click to soapui-pro.bat and choose to edit. (If you are using the community version, the name of the bat file will be different)
Then go to line 29 which starts with set JAVA_OPTS=-Xms128m... and insert time-zone parameter: -Duser.timezone="Turkey". Now execute the bat file, it's going to start to work properly!