file.lastModified() not updated , although I change the file content , I work on Windows.
I use File of java , what could be the problem ? Do I need to do some kind of refresh from the code ?
Java, at least 1.8 appears to be caching file attributes. I created a C++ application that uses the Win32's FindFirstFile to get the file information and verify that the last modified value is updated every time. And it does. But Java's File and Files both seem to not always get the latest value. Even tried a one second delay between writes and it didn't always get updated. I'm using Files.write to modify the file so I would hope it's closing it. Not sure if there's a good solution for this in Java, which is unfortunate.
UPDATE:
I found that Files.getLastModifiedTime is a solution for this. But it's only available for Java 1.8 or later.
This behaviour is platform-dependent. Windows doesn't update the metadata of a file being modified until it is closed.
If the file was loaded from the classpath resources, files.lastModified() might not detect the change after an edit is made.
However, when the file was loaded from the outside of the application, it did work well in my case (Windows 10, Java 10).
I've tested it by running files.lastModified() on a scheduled thread, the file reference was loaded once at the JVM startup.
So depending on how your file is loaded, it might affect how file modification is read.
If you are setting lastModified time. it should work fine
File file =new File("fileName");
// other operations
file.setLastModified(new Date().getTime()); // set time
Now you can get lastUpdated time back.
file.lastModified();
Related
I have a Problem with shared access of an EXCEL File append by a JAVA Program. All works fine until the file is not accessed by other and still open, while the program runs again - at least every 10 minutes.
The API tell me something like the file is use and cannot open for writing. Normally a good idea, but exist a way to get arround this behavior? What means in fact: a switch, a value or something special to ignore this?
Unfortunately I don't think you can simply ignore this. If you're not changing file, maybe you can just make a copy of it or catch an exception and try again one minute later?
I want to keep track of multiple files in a location in a unix box, and delete them if no one is using them for a long time.
I am trying to search for reference counting but did not get much help on google.
I also saw FileTime in java 7 which can give me the last accessed time , but i have to the above work using java 6.
If anyone has any ideas or good reference to reference counting and how i can use it, it will be great.
You can use apache common IO. Set observer on your dir which checks the dir and notifying listeners of create, change or delete eventslisten. By this it is possible to track on which dir has been working by user and others are not.
Okay, so we want last access time.
You can have a read of Get the Last Access Time for a File for some further info.
You could try and have a look at http://jdevel.wordpress.com/2011/04/08/file-last-access-time-in-java-on-linux/ for a possible soultion, but this is Linux, not Unix.
Finally, you could borrow the same idea and use JNA or JNI
There is no module for File watching till JDK 1.6. What you can do is, you can write your own file watcher by seeing the
lastModified() method of the java.io.File class.
It returns you the last modified time as a long value and you keep a watch on this file during a regular interval. If the total time difference
(presentTime - lastModifiedTime)
exceeds you time criteria, you can delete the file.
Is there a way in java to set the access time without setting the date modified time as well?
This will be in essence a touch -a command.
the setLastModified method in File updates both the access time as well as the date modified.
We are currently using java 6. Moving to 7 wouldn't be out of the question.
You can use Files.setAttribute() from Java 7:
FileTime fileTime = FileTime.fromMillis(millis);
Files.setAttribute(path, "lastAccessTime", fileTime);
The string "lastAccessTime" can be found in the description of the BasicFileAttributeView, which also provides an alternative way to set this property (together with Files.getFileAttributeView()):
Files.getFileAttributeView(path, BasicFileAttributeView.class).setTimes(null, fileTime, null);
I'm not aware of any pure Java way that works in Java 6 or earlier.
I guess opening an input stream on the file should modify its access time. But I don't know of any API to directly modify this attribute in Java 6.
There is a private sun API to check access time on a file(How to prevent ShellFolder.getFolderColumns(...) from crashing a lot), but no way to set it from what I've found. Though access time should be updated everytime you open the file, so maybe try opening it in Java.
You could check if the old JDIC project has the option: http://javadesktop.org/articles/jdic/index.html
Or this library: http://www.teamdev.com/jxfilewatcher/
Otherwise you might have to look up the console command for the OS's you want to support and call from Java.
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 am developing a Java Desktop Application. This app needs a configuration to be started. For this, I want to supply a defaultConfig.properties or defaultConfig.xml file with the application so that If user doesn't select any configuration, then the application will start with the help of defaultConfig file.
But I am afraid of my application crash if the user accidentally edit the defaultConfig file. So Is there any mechanism through which I can check before the start of the application that whether the config file has changed or not.
How other applications (out in the market) deal with this type of situation in which their application depends on a configuration file?
If the user edited the config file accidentally or intentionally, then the application won't run in future unless he re-installs the application.
I agree with David in that using a MD5 hash is a good and simple way to accomplish what you want.
Basically you would use the MD5 hashing code provided by the JDK (or somewhere else) to generate a hash-code based on the default data in Config.xml, and save that hash-code to a file (or hardcode it into the function that does the checking). Then each time your application starts load the hash-code that you saved to the file, and then load the Config.xml file and again generate a hash-code from it, compare the saved hash-code to the one generated from the loaded config file, if they are the same then the data has not changed, if they are different, then the data has been modified.
However as others are suggesting if the file should not be editable by the user then you should consider storing the configuration in a manner that the user can not easily edit. The easiest thing I can think of would be to wrap the Output Stream that you are using to write the Config.xml file in a GZIP Output Stream. Not only will this make it difficult for the user to edit the configuration file, but it will also cause the Config.xml file to take up less space.
I am not at all sure that this is a good approach but if you want to go ahead with this you can compute a hash of the configuration file (say md5) and recompute and compare every time the app starts.
Come to think of it, if the user is forbidden to edit a file why expose it? Stick it in a jar file for example, far away from the user's eyes.
If the default configuration is not supposed to be edited, perhaps you don't really want to store it in a file in the first place? Could you not store the default values of the configuration in the code directly?
Remove write permissions for the file. This way the user gets a warning before trying to change the file.
Add a hash or checksum and verify this before loading file
For added security, you can replace the simple hash with a cryptographic signature.
From I have found online so far there seems to be different approaches code wise. none appear to be a 100 hundred percent fix, ex:
The DirectoryWatcher implements
AbstractResourceWatcher to monitor a
specified directory.
Code found here twit88.com develop-a-java-file-watcher
one problem encountered was If I copy
a large file from a remote network
source to the local directory being
monitored, that file will still show
up in the directory listing, but
before the network copy has completed.
If I try to do almost anything non
trivial to the file at that moment
like move it to another directory or
open it for writing, an exception will
be thrown because really the file is
not yet completely there and the OS
still has a write lock on it.
found on the same site, further below.
How the program works It accepts a ResourceListener class, which is FileListener. If a change is detected in the program a onAdd, onChange, or onDelete event will be thrown and passing the file to.
will keep searching for more solutions.