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?
Related
I'm creating a program in Java that needs to create a file that will store a list of files accessible for various users. However I want to lock the file such that you couldn't just go to the file path outside of the program and view/change the file. Is there a way to do this?
Edit: I was looking into FileLock, but I couldn't tell if that locked the file just while the program was running, or if it locked it all times for anything trying to access it.
I think you are going the wrong way : you need the OS to make a file read-only and everybody with enough privileges will be able to override this and modify the file.
Instead of locking the file just encrypt it. It would be much more appropriate for your needs. See https://stackoverflow.com/a/27962481/1980659 for easy file encryption in Java.
I'm trying to monitor files in java. When a file modification will happen I want to know:
Which process did the change.
What has changed.
Also, I know that there is a way to change the "last modified date" in a file, so I want to check if someone has changed that field.
I tried "commons.io", "DefaultFileMonitor" and "WatchService", but all the information I could get from them was if a change has occurred and the file that was changed.
Unless you're on a weird OS I know absolutely nothing about, you would need to use some mechanism you implement to track who is changing your file. The OS doesn't keep track of that. It also doesn't track what has changed.
So I don't believe you can do #1 unless you can get every process that MIGHT change the file to track that it did a change.
You could do #2 if you kept copies of the file then do a comparison.
I am pretty sure you cannot do that. Neither OS nor Java is storing such information. Maybe using some kernel calls.
There's a file I wanted to get into, but whenever I try to open it I get the message "The process cannot access the file because it is being used by another process".
Well, I want in! So, how can i do it?
I've been brainstorming a few ways to try, I'm hoping to get some input on other ways, or if my ideas wouldn't work for some reason that is not apparent to me.
Idea 1 The folder knows where the file is, it just won't open it. What if I create a program to read from the memory address of the file, copy it, then rebuild it somewhere else? I'm not sure if this has hope, because it relies on the file being the issue.
Idea 2 How does my process know that another process is using the file? If it's checking against all the other processes, maybe I can also figure out which process is using that file and pause it or end it.
Either of these ideas will probably take me weeks. Is anyone more creative and can think of another way; or more knowledgeable and eliminate an impractical idea?
In Windows, applications are allowed to obtain exclusive locks on files. When the process opens the file, one thing you specify is who else can access it while your process does (those are the .NET methods, but equivalents exist in other languages). Excel, for example, is notorious for getting an exclusive lock when you open a file. The way around it is usually to find the offending process and kill it to break the lock. Unlocker is the app that I'm most familiar with to accomplish this. If the process is a System process, however, you may not be able to kill it. You'd have to reboot to reset the lock.
Reading directly from another process's memory is unlikely to be reliable. The application may not have an in-memory copy, may not have a complete in memory copy, may not have a consistent in memory copy, and may not have an in memory copy that matches what's on disk (If they're editing the document, for example).
Your process knows that the file is locked because when it tries to open the file, it does so by asking the operating system for access to the file. The operating system responds saying, "Request denied. Another process has this file open and locked." The OS doesn't tell your process what process has the file open because trying to open a file doesn't include asking for who already has it open. Your process must ask the right question to get the answer you're looking for.
Windows makes you specify a sharing modes when opening a file. The sharing mode may prevent the file from being read, written, or deleted while you have it open. If you want to allow simultaneous read access you should include FILE_SHARE_READ in the dwShareMode parameter when you call CreateFile (http://msdn.microsoft.com/en-us/library/windows/desktop/aa363858(v=vs.85).aspx).
In other words, if you want to enable concurrent access to an open file you must modify the way the file is opened in the first place.
The portable standard libraries in C and Java don't offer a way to set the sharing mode when opening a file, but their usual implementations on windows set the sharing mode to READ+WRITE.
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();
I'm trying to edit configuration file in Java. What I really need to do is to change single line, so reading the whole file and writing it back would be waste of time, since configuration file can be big.
Is there a more efficient way to do this? Except reading in/editing/writing out file. I thouhgt of converting entire file to string, replacing the line I want and writting it back.
I don't know how efficient would that be, can someone give me some other suggestions or the one I mentioned are ok, execution time is important.
I would recommend to use the Preferences API instead. Then on the Windows platform your preferences is stored in the registry. On other platforms the corresponding way to save application preferences is used. See also Preferences API Overview.
How big of a configuration file are we talking here? 1k lines? 10k? 1m lines? If the line you want to edit is the last line, just seek to the start of the line, truncate the file there and write the new one. If it's not... you will need to read it whole and write it again.
Oh, and the 2 options you mention are actually the same (read/edit/write).
On the third hand, I think it's irrelevant (unless you have weird constraints, like a flash storage device which takes too long to write, and has limited write cycles), given the sizes of most config files.