I have scenario where I need to detect recently moved file in a directory. Option are available which says check the last modified date then we can pick up.
But in my case even if the file comes there is a possibility that its modified date is older than already existing files.
So Is there anything we could write any code snippet who could just detects the latest moved file ? Just based on movements but not any last modified date.
Ideas...?
EDIT:
Operating System using: Windows
If you want to keep track of what is going on within one or more specific directories (folders) then use Java's Watch Service API which is part of the java.nio.file package.
This API can detect when a file is moved, copied, or created within the specified directory. Even when a file is edited, modified, or deleted from within the very same directory.
Read the information within the supplied Oracle link above and try the demo application which can be downloaded (copied) from within the Try It Out section. I think it's just what you may be looking for.
Related
I am writing a piece of software that is to monitor the time a file was added into a specific directory. I would need to do this in both c# and java. However, I am not so much interested in when the files was created as this could be days before they are actually moved into the directory of interest. I have been loking around, but unable to find anything. The closest I've found so far in java is:
File file = new File(yourPathHere);
long lastModified = file.lastModified();
But that does not give me the time the file was moved into the folder. Thanks for help :)
if you are using windows, have a look at this rules :
https://support.microsoft.com/en-us/kb/299648
It seems that when you move a file, it does not change its modification or creation date.
It's changed only when doing a copy.
As an alternative, you can regularly scan your folder, like every 1 minutes and when you discover a new file, you put it in a log and write it's discovery date.
As IInspectable is saying, FileSystemWatcher and FindFirstChangeNotification are probably the way to go to avoid coding a scanner
I'm opening many types of files using external applications which are available on phone. For security reasons I need to delete this file when the external app does not need it. How can I check if I can safely remove file which are used by third app ?
First of all you need to know which files are used by the third app. You can simply do it by analyzing, (decompiling, if needed) the source code of the application. After knowing all the files used by the third party app you need to check if the third party app actually running or not, because the third party app might use some temporary files, which could be removed when it's no longer open.
If you just want to make a simple cleaner, which cleans the trash of all the apps, then you should simply just remove certain file types (like .tmp files) and remove the cache of the apps.
First of all, I think there is no 100% way to determine if file is not used by another application.
I you are asking about files in sandbox of other apps, by the way you be able to remove such files because they have granted permissions only for app that they are belong to. So you need root access in this case.
You can remove file like cache,tmp ... files like system app manager does. If third-party is built correctly this should not affect application.
Also another method is to determine how often file is being used is based on unix file timestamps, they are
Access - the last time the file was read
Modify - the last time the file was modified (content has been modified)
Change - the last time meta data of the file was changed (e.g. permissions)
You can check for example the date when app was installed, than check access time of the file and determine does the application require this file.
But again there is no 100% guarantee that you won't brake an app.
I have a large directory containing files that are modified by a seperate system at varying intervals. I am running a watcher on this directory to detect which files are modified.
I'm wondering if there is some sort of trigger that occurs when a file is accessed by the system for modification. If so, the following would apply:
Using Java, is it possible to detect which files are about to be modified and make a temporary backup before that happens?
Alternately, is it possible to compare the newly modified file against it's previous version?
In this scenario, it is impossible to make a back up of every file as the files are large and there are many of them.
Example:
I have four files:
a.xml
b.xml
c.xml
d.log
b.xml has a new section added.
Is it possible to copy the newly created section into d.log?
I can think of one way which could be a possible solution to your problem.
"Maintain a log file which tracks lastModified date of each files and you can verify which file has been modified by using your log file.
--
Jitendra
No. you can not detect a file that will be modified. not until they come up with a highly accurate future predicting AI system.
your best approach would be to maintain a versioned backup of the the files. I would start with looking into some source code management system design considerations.
How would you know if the files are about to be modified? The system handles all of the file IO. The only way you could do that is to have the program doing the modification trigger the backup, and then make the modifications. For comparison, it depends on what you want. If you want a line-by-line comparison, that should be fairly simple to do using Java's file IO classes. If you just want to check if they are the same or not, you can use a checksum on both files.
My program needs to read a list of files from a Perforce repository using the Java API provided by Perforce. This program uses a shared read-only login, and fetches files without using a client workspace.
This all works fine, however the problem I have is that the files always appear to be checked out with \r\n line endings. I have tried various naughty hacks (e.g. setting the System property line.separator to \n), but these don't work. I have noticed that the line-ending style in the p4v client is set on the workspace. Am I required to have a workspace to set the line-ending style?
Unfortunately, whilst there are a few files which never change, and I can commit those as binary, the other files I retrieve cannot be committed as binary.
Yes - the line ends of local files are determined by the client (aka workspace) setting when calling "sync".
If you fetch files without syncing and without a client then you have to "print" them.
In that case you would have to do the line end translations yourself.
Perhaps you can sync the files by creating a temporary client.
Here's an example for that (look at method P4PublishTransaction).
I am doing a project in java and in that i need to add and modify my
text file at runtime,which is grouped in the jar.
I am using class.getResourceAsStream(filename) this method we
can read that file from class path.
i want to write into the same textfile.
What is the possible solution for this.
If i can't update the text file in jar what other solution is there?
Appreciate any help.
The easiest solution here is to not put the file in the jar. It sounds like you are putting files in your jar so that your user only needs to worry about one file that contains everything related to that program. This is an artificial constraint and just add headaches.
There is a simple solution that still allows you to distribute just the jar file. At start up, attempt to read the file from the file system. If you don't find it, use default values that are encoded in you program. Then when changes are made, you can write it to the file system.
In general, you can't update a file that you located using getResourceAsStream. It might be a file in a JAR/ZIP file ... and writing it would entail rewriting the entire JAR file. It might be a remote file served up by a Url classloader.
For your sanity (and good practice), you should not attempt to update files that you access via the classpath. If you need to, read the file out of the JAR file (or whatever), copy it into the regular file system, and then update the copy.
I'm not saying that it is impossible to do this in all cases. Indeed, in most normal cases you can do it with some effort. However, this is not supported, and there are no standard APIs for doing this.
Furthermore, attempts to update resources are liable to cause anomalies in the classloader. For example, I'd expect resources in JAR files to not update (from the perspective of the application) until the application restarted. But resources in exploded JAR files probably would update ... though new resources might not show up.
Finally, there are cases where updating a resource is impossible:
When the user doesn't have write access to the application's installation directory. This is typical for a properly administered UNIX / Linux machine.
When the JAR file is fetched from a remote server, you are likely not to be able to write the updates back.
When you are using an arbitrary custom classloader, you've got no way of knowing where the actual bytes of an updated resource should be stored, and no way of storing them.
All JAR rewriting techniques in Java look similar. Open the Jar file, read all of it's contents, and write a new Jar file containing the unmodified contents (and the modifications you whished to make). Such techniques are not advisable for a Jar file on the class path, much less a Jar file you're running from.
If you decide you must do it this way, Java World has a few articles:
Modifying Archives, Part 1
Modifying Archives, Part 2
A good solution that avoids the need to put your items into a Jar file is to read (if present) a properties file out of a hidden subdirectory in the user's home directory. The logic looks a bit like this:
if (the hidden directory named after my application doesn't exist) {
makeTheHiddenDirectory();
writeTheDefaultPropertiesFile();
}
Properties appProps = new Properties();
appProps.load(new FileInputStream(fileInHiddenDir));
...
... After the appProps have changed ...
...
appProps.store(new FileOutputStream(fileInHiddenDir), "Do not modify this file");
Look to java.util.Properties, and keep in mind that they have two different load and store formats (key = value based and XML based). Pick the one that suits you best.
If i can't update the text file in jar what other solution is there?
Store the information in any of:
Cookies
The server
Deploy the applet using 1.6.0_10+, launch it using JWS and use the PersistenceService to store the information. Here is my demo. of the PersistenceService.
Also, if your users will agree to a trusted applet (which seems overkill for this), you might write the information to a sub-directory of user.home.