I am working on a directory syncing program that uses jnotify to check for changes.
The idea is whenever jnotify detects a change, a sync is performed. The problem is that when many files are copied to or modified in a directory, many syncs are performed instead of one large sync.
Ideally if you were to copy 100 large files to directory A, the sync to directory B would not occur until all the files are fully copied to directory A.
I have thought about somehow using a temp directory (A1) to hold files until they are fully copied and then moving them into A1. But this solution does not work well because I am using unison to perform the sync which only sends file deltas - and that is a feature I would like to use and not circumvent.
Perhaps there is a way to use i/jnotify to detect when multiple files are being updated at once?
Here's a suggestion. How about setting up a set on your application and have it collect up "modified" files/etc it would add that file to a set and when the number of files exceed a certain amount of number, say 100, you would then do a sync. It would also be a good idea to set up a timer too if you want it to be reasonable responsive, like if there is no new changes/etc that is being added to the set for X amount of time go ahead and do a sync also.
Related
I use a File-Endpoint to read files. After Camel reads the file it moves the file to the subfolder .camel. So thats OK, and thats what I want. But after some months there are thousends of files.
It is possible to remove automaticly files older than x weeks? Without external tools? Is there an option for the File-endpoint? I don't find anything.
Thanks a lot
No there is no such support or tool. Usually you move files to some backup folder, and then you have some other system that takes care of house keeping those files.
It's not suitable to let Camel monitor for files older than X and delete them, even though you can build a route doing that.
Often your sys admins have their own way of managing their infrastructure.
i have an application which accesses a chosen file and reads the data(text in my case) inside it and does some calculations then updates the text and rewrites it into the file.
the application works perfectly fine in terms of accessing files and rewriting them except in one case
here is the case: if the user uses a Desktop and if the user triggers an event that leads to file operations(reading and writing) and in the same time power got cut then after launching the desktop again the file still exists but it has no data in it(it is entirely emptied)
keep this mind that this is only happening when using a Desktop(it doesn't occur on laptops) and only exactly if a file operation has been triggered a split second before the power outage.
i was wondering is there any workaround in java to prevent happening such a thing, i know chances of this happening is very low but it happened and that is why i am here.
If the power goes off while you are writing a file, there are no guarantees1 that the file will be written completely.
You can use FileDescriptor.sync() to reduce the window of vulnerability (by forcing the OS to flush writes to physical disk), but you can't eliminate it completely.
But as #creinig says, the normal way to do this is to write the data into a temporary file and then rename the temporary file. Many OSes can perform a file rename operation atomically.
Incidentally, you say this:
This is only happening when using a desktop computer (it doesn't occur on laptops) ...
A laptop typically has a battery and is not vulnerable to physical power cuts. When you press the power-off button on a laptop, the OS probably gets a chance to flush the file system before the laptop powers down.
1 - Certainly not with a conventional file system. A transactional file system (e.g. Transactional NTFS) may offer some guarantees, but I'm not sure if the Java runtime understands this.
The classical solution to this would be to write the changed contents to a temp file and afterwards rename the temp file to the correct name. That way an interruption (a) leaves the temp file empty and the original file untouched or (b) causes the temp file to not be renamed, leaving the original file untouched.
I'm currently trying to write a simple journal-like program in Java that allows me to add "entries" and be able to browse all the "entries" I have added since the very beginning. The problem is, if I run the program, add two entries, exit the program, and then run the program again, I want to be able to have access to the two entries I previously added. I guess my questions is then, how am I able to "save" (if that's the right word) the entries that I add so that they won't be wiped out every time the program terminates?
I did some looking around, and it appears there's a tool I can use called the Java Cache System, but I'm not entirely sure if that's what I need for my situation. I'd appreciate if somebody could point me in the right direction.
When you run the program and create the entries your storing them in primary storage aka RAM. As you have discovered these entries will not persist across different executions of your program.
You need to store the entries in secondary storage aka the hard drive. This can be done by writing the entries to a file saved on disk and then reading those entries upon startup of the program. Java provides several mechanisms to read and write files to the file system on a machine.
Some applications use a database to store information in a relational manner so that it is available via a SQL request, however I would recommend using a simple file to store your entries.
The simplest way would be to store this data somehow in a file, and then read it from the file when the application starts, a few simple examples on how to write/read from file:
http://www2.cs.uic.edu/~sloan/CLASSES/java/MyFileReader.java
http://www2.cs.uic.edu/~sloan/CLASSES/java/MyFileReader.txt
http://www2.cs.uic.edu/~sloan/CLASSES/java/MyFileWriter.java
http://www2.cs.uic.edu/~sloan/CLASSES/java/MyFileWriter.txt
Now, you store your objects in memory instead of this you can try to serialize them to some format like xml. And then in next run load them from xml. Or you can try to use dataBase for storing objects.
I faced same problem in past but little bit different.I clearly understood your problem , My solution is whatever the journal you are entering and getting saved should be saved in a particular location in your Location such as "C:\Your_Directory\Journal_folder\"
so it will be easier when you initially enter the journal it stores in above location ,again if u exit and reopen the application just try to retrieve the data from the above Mentioned target Location.
therefore every time when ever you enter the application it retrieves the data from that location if not it displays empty
I want to compare or get delta of two files that means if a file or directory has just been renamed or moved or changed into another folder will handle these operations like a deletion and subsequent file (re)creation, resulting in re-transmitting the entire file or even directory to the mirror location at the new location or with the new name or a file that made changes then how can i get that changes not the whole file.
How can i achieve this in java or android.
It sounds like you need something like rsync. There is a Java implementation
http://sourceforge.net/projects/jazsync/ so you might want to look into that. I'm not sure how stable it is or how well it works with Android.
I have to create a jar with a java application that fulfills the following features:
There are xml data packed in the jar which are read the first time the application is started. with every consecutive start of the application the data are loaded from a dynamically created binary file.
A customer should not be able to reset the application to its primary state (e.g. if the binary file gets deleted for some reason, the application should fail to run again and give an error message).
All this should not depend on the os it is running on (which means e.g. setting a registry entry in windows won't do the job)
Summarizing I want to prevent a once started application to be reset in order to limit illegitimate reuse of the application.
Now to my ideas on how to accomplish that:
Delete the xml from the jar at the first run (so far I came to the understanding that it is not possible to let an application edit it's own jar. is that true?)
Set a variable/property/setting/whatever in the jar permanently at the first run (is that possible)
Any suggestions/ideas on how to accomplish that?
update:
I did not find a solution for this exact problem, but I found a simple workaround: along with my software I ship a certain file which gets changed after the program is started the first time. of course if someone keeps a copy of the original file he can always replace it and start over.
Any user able to delete the binary file, will, with enough time, also be able to revert any changes made in the jar. When the only existing part of the application is in the hand of the user, you won't able to prevent changes to it.
You can easily just store a backup of the original jar, make a copy, use that for one run, delete, copy the original jar, etc. You would need some sort of mechanism outside the users machine, like an activation server. The user gets one code to activate an account, and can't use that code again.