We Keep Coding

How to open a file in Java that does not prevent external "Safe Save"?

We want to open a file in Java and read its contents.
This file may be updated by an external application using Safe Save. That means the file will be externally read and its updated contents will be stored to a new file. Eventually the original file is deleted and the new file is renamed to match the original file's name.
Unfortunately the external process fails during rename (last part of the Safe Save) when our Java Application is reading the original file at the same time.
We played with different kind of open modes but could not get a solution that does not fail the external reader.
Is there some way to open a file that does not interfere with external processes accessing the same file? Ideally, whenever an external process moves or deletes the file we would like to get an exception in our Java application. And only there.
Do you have any ideas on how to achieve that?
EDIT:
Just some clarification regarding the use case:
This an indexer like scenario. We want to index contents of a potentially very large filesystem where 3rd party independent processes can concurrently read from or write to as well. We have no control over the 3rd party processes.
Copying the original file seems like a big overhead and we are not sure if that helps with the original problem as it will probably fail the external reader on a Safe Save as well.
Last but not least: This should work on Windows and Linux. But we are experiencing this problems on Windows.

On Windows, whether a file can be renamed or deleted while it's open is controlled by the FILE_SHARE_DELETE sharing mode flag. This flag should be passed in when the file is opened with the low level CreateFile function.
Unfortunately, Java API does not give you control over low level Windows-specific flags. There is an open bug report to have FILE_SHARE_DELETE added by default, but it's unlikely it will be done because of backwards compatibility (some applications may depend on this behavior). the A comment in the report suggests a workaround: instead of new FileInputStream(file) use the java.nio API.
InputStream in = Files.newInputStream(file.toPath());
I don't have access to Windows right now to verify that this workaround uses the right sharing mode.

Make a copy of the original file an use this within your Java program, and at the same time keep track of the original file.
Here, this might help you out:
The java.nio.file package provides a file change notification API, called the Watch Service API. This API enables you to register a directory (or directories) with the watch service. When registering, you tell the service which types of events you are interested in: file creation, file deletion, or file modification. When the service detects an event of interest, it is forwarded to the registered process. The registered process has a thread (or a pool of threads) dedicated to watching for any events it has registered for. When an event comes in, it is handled as needed. Official docs

You cannot achieve this only with files, at least not without making additional assumptions. If the processes are not synchronized you will get either (a) errors (b) corrupted data or (c) both. Furthermore, such system will be unstable, prone to race conditions and implementation-specific details. This means that even if it looks like it's working it will not work correctly always and in each case.
Depending on your circumstances you might try to use a combination of scehduling (i.e. process A runs every even minute, process B every odd minute), exclusive/shared open flags, range locks, copying files, file change notifiers, retrying on failure etc. If you can somehow ensure that your assumptions are never broken you might end up with something which is "good enough". But all in all, this is a bad engineering practice and should be avoided.
For a proper solution, you need to make both processes aware that they are talking to each other. What you have is really a textbook use case for a database. Besides using a database there are plenty of other ways to synchronize access to data - messaging, streams, locks, shared memory etc. Each way has its own benefits and downsides and without knowing more about your specific situation it is impossible to say which would be better.

Lock future file

So I have a Samba file server on which my Java app needs to write some files. The thing is that there is also another php application (if a php script is even considered an application) that is aggressively pulling the same directory for new files.
Sometimes, the php script is pulling the file before my Java app is done writing it completely to the disk. Here is a little bit of ascii art to help visualize what I currently have (but doesn't work):
Samba share
/foo (my java app drops file here)
/bar (the directory that the php is pulling)
What I'm currently doing is when the file meets some criterias, it's being moved to /bar and then picked up by the php for more processing. I've tried different thing such has setting the file non writable and non readable before calling renameTo.
I've looked a little bit at FileLocks but it doesn't seem to be able to lock future files. So I am wondering what kind of possiblities I have here? What could I use to lock the file from being picked up before it's fully written without touching the php (because, well, it's php and I don't really have the right to modify it right now).
Thanks
Edit 1
I've got some insight on what the php script is really doing if it can help in any way.
It's reading the directory file in loop (using readdir without sleeping).
As soon as it finds a filename other than "." and "..", it calls file_get_contents and that's where it fails because the file is not completely written to disk (or not even there since the Java code might not even had time to write it between the readdir and file_get_contents.
Edit 2
This Java application is replacing an old php script. When they implemented it, they had the same problem I'm having right now. They solved it by writing the new file in /bar/tmp(with file_put_contents) and then use rename to move it to bar (it looks like rename is supposed to be atomic). And it's been working fine so far. I can't and won't believe that Java can't do something better than what php does...

I think this is due to the fact read locks are shared (multiple process can apply read locks to the same file and read it together).
One approach you can do is to create a separate temporary lock file (eg: /bar/file1.lock) while /bar/file1 hasn't finished copying. Delete the lock file as soon as the file copying is finished.
Then alter the php code to ensure the file isn't being locked before it reads.

You mentioned that you tried FileLock, but keep in mind the disclaimer in the javadoc for that method:
Whether or not a lock actually prevents another program from accessing
the content of the locked region is system-dependent and therefore
unspecified. The native file-locking facilities of some systems are
merely advisory, meaning that programs must cooperatively observe a
known locking protocol in order to guarantee data integrity.
You also mentioned you are using File.renameTo, which also has some caveats (mentioned in the javadoc):
Many aspects of the behavior of this method are inherently
platform-dependent: The rename operation might not be able to move a
file from one filesystem to another, it might not be atomic, and it
might not succeed
Instead of File.renameTo, Try Files.move with the ATOMIC_MOVE option. You'll have to catch AtomicMoveNotSupportedException and possibly fall back to some alternative workaround in case an atomic move is not possible.
You could create a hardlink with Files.createLink(Paths.get('/foo/myFile'), 'Paths.get('/bar/myFile')) then delete the original directory entry (in this example, /foo/myFile.
Failing that, a simple workaround that doesn't require modification to the PHP is to use a shell command or system call to move the file from /foo to /bar. You could, for example, use ProcessBuilder to call mv, or perhaps call ln to create a symlink or hardlink in /bar. You might still have the same problem with mv if /foo and /bar are on different filesystems.
If you have root privileges on the server, you could also try implementing mandatory file locking. I found an example in C, but you could call the C program from Java or adapt the example to Java using JNA (or JNI if you want to punish yourself).

Preventing fake client data Java?

I am writing a plugin for the popular Minecraft server software, Bukkit.
My plugin will require sending player scores to my server, to work out a global leaderboard.
Seeing as Java can be decompiled, someone can decompile the plugin, and find out how it works (It's open source anyway). I am looking for a method of sending data to my server (player scores), in such a way so it can not be spoofed, and the leaderboards cannot be rigged.
I was considering making the plugin's users (server owners) sign up to the leaderboards site, and then use their own username/password combination to connect to my leaderboards. If it was abused, I could simply block that server from the leaderboards. This is not the most efficient method however, as I would have to administrate the joins and approve the amount of kills.
How would I go about making sure the client (Bukkit Server Plugin) can't spoof kills?

If your concern is that a legitimate user is educated enough to decompile your jar, understand your code and figure out how to send wrong data from your plugin, authentication methods are of no use (the user is already legitimate) and I assume the logic that calculates what you want can not reside in the server. In this case your best option would be to obfuscate your code

Making it open source is what's stopping you. If it was closed source you could obfuscate your jar and it would be much harder to decompile your code.
If you still want it to be open source, you could keep an eye on rapidly growing servers or very high scored servers. But like you said, that's very inefficient.
Post on the Bukkit forums, they might have a better answer for you.

Serving Java Applets from a Queue?

I'm looking for a elegant way to create a queue for serving up batch compiled applets.
I have hacked together a SQL and PHP script to handle this but it chokes under mild loads.
is there an existing system that can handle taking a list in SQL and serve the applets in descending order each time it is requested. I'm also trying to handle this all server side as well.
The trick would be getting file001, then file002 ++ ect. to get served each time a web page is loaded. I'm batch creating applets that has a slightly modified background and I'm trying to serve a never been used applet waiting in the queue to load each time the a page is requested.
Is there a applet server I can tweak or does look like something that needs to be built?

No, I have never heard of a "batch compile applet server".
Could you maybe explain in more detail why you feel this is necessary?
Why don't you just use the same class and pass parameters to it?
That said, you can do compilation on demand quite well with e.g. ant and / or CruiseControl. You could put the pre-compiled applets into a directory. Then your PHP frontend just needs to keep track of what applet it delivered last, and fetch the next one the next time.
Still, this sounds rather complicated to me; so maybe you could explain your motivation.
In particular, why do you want a new applet on every reload? Would that not be rather confusing? Why not offer a link for each variant, so the user can choose?

web-browser based GUI

I am working on an application in Linux which will interfaces with hardware. One of the requirements is to create the GUI in Web-browser . the application will be c++ based. I m not familiar with web realted stuff so i want to know Is it possible to do such a thing (currently it's a console application take input from txt file/cmd line). gui will be simple using button and showing output messages on browser from the application. i want to know which technologies/languages are involved and how can it be done. some of the idea i read but havn't found anything concrete yet. if u have any idea about these or a better suggestion please share
run the app in background and communicate with browser ?
call library functions directly from browser ?
any other idea ?

I would start by setting up a regular HTTP server, like lighttp or Apache httpd.
You say you already have a command line program that does the actual work - As a first step, I would reuse that, and configure the web server to call your program using CGI - see forexample http://httpd.apache.org/docs/2.2/howto/cgi.html for apache
Finally, I'd pick some javascript framework like jQuery or YUI with Ajax capabilities to do requests to the server to call the CGI script from within a webpage. You could also create a form-based web application without ajax or any framework, but that would require you to stuff all kinds of logic in your program to generate HTML pages. By using Ajax, you can leave the command line application as is, and parse any responses it gives with javascript, and then use that to dynamically change the webpage in a way that would make sense to the user.
If this all works, then I would try to figure out how to package all these components. Perhaps you just want to create a simple archive with all the programs inside, or maybe you want to go as far as actually embedding the webserver in your program. Alternatively, you may want to do it the other way around and rewrite your program as an ISAPI module that you can plug into your webserver. Or if that's not integrated enough still you could write your own (partial) HTTP server. That's really up to you (I'd probably spend time and energy on searching for the leanest, meanest existing open source http serverr and use that instead)
At any rate, the prior steps won't be lost work. Most likely, developing the web page is going form a substantial part of the work, so I would probably create a quick and dirty working solution first using the age-old CGI trick, and then develop the webpage to my satisfaction. At that point you can already have an acceptable distributable solution by simply putting all programs in a single archive (of course you would have to tweak the webserver's configuration too, like changing the default port so it won't interfere with existing webservers.) Only after that I would spend time on creating a more integrated fancy solution.

I ended up using Wt though I'd update for future reference.

These are how I thought of doing this, in order of complexity for me:
Create a simple server-side-language (PHP/Python) website that can communicate with (ie launch and process the return of) your application
Modify your application to have a built-in webserver that just punched out HTML (command line parameters taken through the URL)
Modify the app to publish JSON and use javascript on a simple HTML page to pull it in.
You could write a Java applet (as you've tagged this thread) but I think you'd be wasting time. This can be quite simple if you're willing to spend 10 minutes looking up a few simple commands.

After 12 years, web browser-based GUI started to appear, WebUI is one of them.