Possible to force file lock release?

Is there any way to force the JVM to release a lock on a certain file?
I am reading from a BufferedReader wrapped around a FileReader. At some point, an IOException is thrown (I'm reading a file that is being written by another process, and occaisonally this will happen, but I'm handling it so it doesn't really bother me). When this happens, I can not call reader.close(), the lock never gets released, and I can never delete the file I was reading from.
So I'm wondering if there is some way to force it to be unlocked. Ideally a static method like
FileLock.releaseLock(File pleaseReleaseMeLetMeGo)
?????

Well, I do call it, but I'm sure it is throwing an exception (I have a try/catch around just that one call in the IOException handler).
I'm doing this on windows. The only solution I can come up with so far is to launch a separate Java process to shutdown the current process and then delete the file and restart the process in question (it needs to be running continuously). This seems like a really dirty hack though and unnecessarily complicates the program.
Also, it may be possible to open the file I want to delete for writing. I don't really have to delete it, I just want to overwrite what's in it. Sometimes it seems that Java will let you re-write a file even though it won't let you delete it...

Similar Messages

File locking with OSX Server & Microsoft Word

We have a small office LAN based on a Airport Extreme bases station. Periodically Microsoft Word reports a break in connection to the shared folder where we store documents to get disconnected. When that happens and the user reconnects to the share, the user gets the file read-only message for the Word document that was open at the time.
I have found that in order to clear the read-only flag, I have to restart the server and open the Word file on the server with the ID of the user who was editing the file on the remote computer. Only that seems to clear the file locking that causes the file to be read-only.
I cannot figure out a less drastic way to release the lock file. I don't see any hidden temp files in the same folder as the document that is locked for editing found by ls -a or in the root direction of the shared folder in the .TemporaryItems/folders.<UID> that seems to be holding the lock.
I have run chflags nouchg <Word file> from Terminal, but that seems to have no effect either. I also used xattr to see if there were any locks held that way, but I don't see anything that way either.
File sharing to Macs only, which are configured just to use AFP through OSX Server.
Does anyone understand how the file locks of Word documents can be released directly with out restarting the server?
I should add that the underlying problems seems to be WiFi related. The behavior is that the WiFi connection seems to break long enough that the shared volumes disconnects. Outlook also causes a break. This behavior seems to have started with 10.9 and the purchase of new Retina Display MacBook Pros. I turned off AppNap on the Office applications but that is not clearly helpful. I also have been told the problem seems more likely to occur when Word is open in the background and another program like Outlook is in the foreground.
Any suggestions appreciated.

Apple write an operating system and also produce file sharing software as part of that to be used as a file server. Apple provide documentation for third-party software developers on how they should write software to work with Apple's software and also give those developers early access to new versions so those third-party developers can test and if needed make adjustments and issue updates to cope with any Apple changes.
Some third-party developers are good at dealing with this, some are bad, and some totally ignore what Apple does and give the impression they don't care if their product works properly or not. I think we can all judge where Microsoft sits.
It appears Microsoft have never paid any attention in particular to how Apple expect file-locking to be handled when accessing files on a Mac server. There have been problems for years and years and years with Office. Two other problems I have seen which seem different to yours but probably related are -
With Office documents it is supposed to be possible for more than one person to edit the same file at the same time, consider it a miracle if this actually works
With Office in particular Word, there is an auto-save function, unfortunately the way this seems to be implemented it seems that Word creates a new temporary file each time it auto-saves the document and keeps all the previous temporary files open still, this eventually means potentially over a hundred temporary files are open - just for one Word document and you can then hit a limit on the total number of files you are allowed to have open at the same time. At this point further auto-saves fail, and you also encounter great difficulty doing a real full save of the document.
I do not hold Apple completely blameless over this issue, it is likely their file-locking implementations change too often, and have inadequate documentation, however even considering this a company the size of Microsoft with the amount of sales (and profit) they derive from Office for the Mac has no excuses at all for failing to put the effort in to resolve any such clearly critical problems.
We could go on and on about other areas where Microsoft don't play by the (software) rules. Even in Windows Office does not obey the standard print dialog rules Microsoft specified themselves!
Unfortunately not only is Office for Mac upgraded infrequently, but even when new paid for upgrades are released Microsoft have a history of still not fixing bugs. It goes without saying that a mere free update is even less likely to actually fix a bug, typically such free updates only address security issues. The next version of Office is going to be Office for Mac 2014 see http://www.macworld.com/article/2106643/microsoft-will-release-a-new-version-of- office-for-mac-this-year.html
One area I confidently predict Microsoft not to resolve in Office for Mac 2014 is that fact that Word for Mac still does not support right-to-left languages like Hebrew and Arabic. This is despite the fact that OS X itself has supported this for years and years, and despite the fact other Mac programs support this including the free TextEdit and Pages - both of which can read Word files. Some people may remember that at one point the Israeli Government temporarily banned all Microsoft software over this issue. See http://apple-beta.slashdot.org/story/03/10/15/2215249/israeli-government-suspend s-microsoft-contracts This issue goes back over TEN years!!
I note that Microsoft has now taken their OfficeForMac blog offline, probably due to the weight of criticisms. I would not say it is due to out-right anti-Microsoft hate, that war ended long ago. We just want products that work. I myself do use Microsoft products, even at home - where they are the best solution, so I use Microsoft Media Center for example. Sadly this is now being neglected by Microsoft.

File locking issue

hi ,
I use a java applet for ftp images upload using a third party ftp API library (edtftpj).
i run my applet from browser but I'm experiencing a strange issue :
-i upload a file & leave the browser opened.
-i then open this same file with gimp or photo-shop & get 'file in use' error.
-if i close browser & try opening file ,the file is opened correctly.
I investigated the issue more thoroughly and here are my conclusions :
1) First i made sure to close all File's streams in the applet.so I'm sure i eliminated this issue of forgotten opened file streams .
2) also i made sure to close all network connections that might be holding the File lock.
It's clear that another process is still locking the File & preventing access to it.
i used a win32 program (procExp) to monitor active processes . it turned out that javaw.exe is the process that use the File. i was convinced of this fact with a simple experiment : if i destroy the applet (closing applet's browser window -not necessarily all browser instances-) then in this case the file lock is released and i can access and delete File correctly.
my questions :
-How to instruct javaw.exe to release the File lock ? (is that possible at all to do ?)
-is it a bug in JVM ? (i'm using jdk1.4.2)
-or is it an OS centric issue related to windows only ?
i would appreciate your ideas about this problem .
thanks.

Exactly, and I've been aware of all that since about 1997. I don't know whether that was supposed to answer my question to you as the OP but it doesn't.
Sadly I misread your second-last post to say that you are using Thread.stop(), which you're not, so that explains some of the confusion. But I don't understand why you say Thread.interrupt() doesn't release the resources. It isn't supposed to. It doesn't do anything except set a flag and cause your thread to throw an InterruptedException if it's calling Object.wait(), Thread.sleep(), or certain I/O routines. It's up to your thread to react appropriately, and/or to call Thread.isInterrupted at appropriate intervals.
So Thread.interrupt() (a) provides the boolean flag you need and (b) also interrupts your thread under some circumstances. So it is definitely the solution you should be using: call Thread.interrupt() to tell the thread to exit, and call Thread.isInterrupted() in the thread itself to know whether to do so.

XSL File locked after error

Hi,
I've tried to modify a XSL File that I created with Forms Builder. It's all because I want to add some functionality.
Now here is my problem. Because the XSL is not perfect at the moment, it produces some errors while parsing. Unfortunately after that the file is locked on the file system so that I can't change it anymore. So debugging is a little bit hard because I know the error but can't fix it.
Finally my question: Is there a possibility to unlock the file so that I can edit it again (without restart)?

Hi,
Normal PCD objects can be unlocked through System admin->Monitoring, not sure if this applies to XSL files as well.
If the file is locked by a process and cannot be released, you could process explorer to search for the file handle and delete the "file lock" the process has.
See
http://www.microsoft.com/technet/sysinternals/utilities/ProcessExplorer.mspx
dagfinn

File lock() method problem

I know this may be a common question, but can someone explain why this code:
import java.io.*;
import java.nio.channels.*;
import java.util.*;
public class TestFileLock
     private static File file;
     private static RandomAccessFile fileRandom;
     private static FileChannel fileChannel;
     private static FileLock fileLock;
     private static String process;
     public static void main(String[] args)
          process = args[0];
          try
               file = new File("/home/fauxn/work/blast/java/java_blast/test.log");
               //fileWriter = new FileWriter(file, true);
               fileRandom = new RandomAccessFile(file, "rw");
               fileChannel = fileRandom.getChannel();
               for(int i =0; i < 1000; i++)
                    writeLogFile(process + ": happy days\n");
          catch(Exception exception)
               System.out.println(exception.getMessage());
               exception.printStackTrace();
     * Method lockes the logFile and then append the string to the file and unlocks the file.
     * @author Noel Faux.
     * @param s The string to be written to be appended to the file.
     private static void writeLogFile(String s) throws IOException
     System.out.println(process + ": trying to lock the log file");
     fileLock = fileChannel.tryLock();
     while(fileLock == null)
               System.out.println(s + ": waiting!!!!");
               fileLock = fileChannel.tryLock();
     System.out.println(s + ": logfile locked");
          fileRandom.seek(fileRandom.length());
     fileRandom.write(s.getBytes());
          fileLock.release();
          System.out.println(s + ": logfile unlocked");
produces this error:
Invalid argument
java.io.IOException: Invalid argument
at sun.nio.ch.FileChannelImpl.lock0(Native Method)
at sun.nio.ch.FileChannelImpl.tryLock(FileChannelImpl.java:528)
at java.nio.channels.FileChannel.tryLock(FileChannel.java:967)
at TestFileLock.writeLogFile(TestFileLock.java:43)
at TestFileLock.main(TestFileLock.java:23)
on a intel linux box, java 1.4 and this code works fine:
import java.io.*;
import java.nio.channels.*;
import java.util.*;
public class TestFileLock
     private static File file;
     private static RandomAccessFile fileRandom;
     private static FileChannel fileChannel;
     private static FileLock fileLock;
     private static String process;
     public static void main(String[] args)
          process = args[0];
          try
               file = new File("/home/fauxn/work/blast/java/java_blast/test.log");
               //fileWriter = new FileWriter(file, true);
               fileRandom = new RandomAccessFile(file, "rw");
               fileChannel = fileRandom.getChannel();
               for(int i =0; i < 1000; i++)
                    writeLogFile(process + ": happy days\n");
          catch(Exception exception)
               System.out.println(exception.getMessage());
               exception.printStackTrace();
     * Method lockes the logFile and then append the string to
* the file and unlocks the file.
     private static void writeLogFile(String s) throws IOException
     System.out.println(process + ": trying to lock the log file");
     fileLock = fileChannel.tryLock(0, fileRandom.length(), false);
     while(fileLock == null)
               System.out.println(s + ": waiting!!!!");
               fileLock = fileChannel.tryLock(0, fileRandom.length(), false);
     System.out.println(s + ": logfile locked");
     fileRandom.seek(fileRandom.length());
     fileRandom.write(s.getBytes());
     fileLock.release();
     System.out.println(s + ": logfile unlocked");
Any suggestions welcome, or is this a bug????
Thanks in advance :)

Its a known bug. The default tryLock() method calls the parametered
tryLock method as follows
tryLock(0,Long.MAX_VALUE,false);unfortunately under linux the parameter Long.MAX_VALUE is too big for
the underlying OS file locking. This causes the IOException to be thrown
It has been fixed in version 1.4.1 i believe.
For more info
http://developer.java.sun.com/developer/bugParade/bugs/4532474.html
matfud

File Locking!!! Is this a BUG or there is something wrong in my code.

In new JDK v 1.4. new means of file locking are introuced, and it seems it is a little bit buggy yet (or maybe this one isn't a one). though it's better than nothing :)
here is 2 classes. first locks a file, the second attemts to change it.
import java.io.*;
import java.nio.*;
import java.nio.channels.*;
class FileLocker {
static File targetFile = new File ("D:\\Java",
                                     "manual.chm");
public static void main(String[] args)
      throws Exception
    RandomAccessFile fin = new RandomAccessFile (targetFile, "rw");
    FileChannel fChan = fin.getChannel();
    FileLock lock = fChan.lock();
    // to let other process to attempt to change the same file.
    Thread.currentThread().sleep(100000);
    lock.release();
    fChan.close();
    fin.close();
}and the other class
import java.io.*;
import java.nio.*;
import java.nio.channels.*;
class FileWriter {
static File targetFile = new File ("D:\\Java",
                                     "manual.chm");
public static void main(String[] args)
      throws Exception
    // this is better/more secure way to access files.
    RandomAccessFile f = new RandomAccessFile (targetFile, "rw");
    // next line deletes the file content even if file locked.
//    FileOutputStream f = new FileOutputStream (targetFile);
//--this parts is not needed as the problem is in first 2 lines
    FileChannel fChan = f.getChannel();
    if (fChan.isOpen()) {
      System.out.println("File is Opened, can't write");
    } else
      f.write(-1);
}so when i use FileInputStream for open stream to write,
constructor deletes the targetFile (makes it size equal to 0)
at once i create new FileInputStream object. Since, when i
use RandomAccessFile to open stream for writting nothing happens.
after that, f.write (-1); throws exception regardless the way the
uoutput stream was created.
So i think there is some problem in FileInputStream class' constructor.

OK, I know you mean FileOutputStream instead of FileInputStream in the above message. Looks to me like you've discovered a bug in the way Java is locking the file - locking the whole contents of a file (using the no-args lock or tryLock methods) doesn't prevent other programs, including Java, from overwriting some, if not all, of the file. Note that this occurs even on Windows 2000, where exclusive locks appear to be well supported.
I've found a similar problem where saving from Outlook appears to zero the whole of the locked file. Saving from other programs that are a little more careful, such as XEmacs, appears to only (!) truncate the file to 0, as the FileOutputStream does.
From what I can tell, in JDK 1.4.2 RandomAccessFiles respect each others' locks, but nothing else does.

Problem Loading pdf using AxInterop.AcroPDFLib (file locked)

Hi,
I'm currently using AxInterop.AcroPDFLib with C# in a winform application.
Purpose is to display PDF files in my application. Thoose files are located on a share directory.
Everything works fine, the program is installed on multiple pc that display the file at the same time without problem.
BUT, when i open the same PDF file on a computer using acrobat pdf reader, i can't open the same file using the AxInterop.AcroPDFLib dll.
After some deep search on the files, on the servers, ... it seems to be linked with file locking.
Let me explain :
when the file is opened by the AxInterop.AcroPDFLib dll, no lock appears on the server ( share directory ) or at least it appears and is released in the same second.
when i open the PDF file via acrobat reader, the lock is set, and remain until i close the file in the pdf reader.
which means that when someone open a file, all the computer using the AxInterop.AcroPDFLib ares blocked and can't start reading the file.
Is there a way to configure the AxInterop.AcroPDFLib to allow reading on locked files (locked for reading)
Thanks
Mike

I have tried with both Reader 8.xx and 9.xx
Same behavior.
After deep investigation, i have found that when i open a file using the reader, this file is marked as opened for "read" on the server, and in that case, the ocx can't open the file...
when the file is close by the reader, the lock is removed and the ocx could open the document.
I found also that when the ocx open the file, this file is not locked on the server, which allows other computers with the same ocx to open the same file on multiple workstation (which is the behavior i was expecting).
thus why is the ocx blocked when a file lock is present on the server for the file to be opened by the ocx...
Mike

How to put a file lock on the contents of a folder and sub folders?

Initally I recursively went through the children of the folder and created a file lock for each child, however after abour 2025 locks i recieved a Too many open files exception.
Is it possible to lock a folder such that the contents of the folder cannot be changed? and would that stop the Too many open files Exception?

Hmm.... I would have thought that this was a reasonably common problem. If no-one here can help directly, can someone point me to a forum or similar which may be able to help me?
Cheers

File Locks and SMB shares with ML

I've been doing a lot of research on SMB and the way it locks files during access. I've made a lot of ground work in my research but could use a little further assistance from this support community.
The symptom is simple to explain: Users are occasionally being prompt for a username and password when attempting to rename or move files and folders.
After doing some research on this topic, I have discovered that there is a direct relationship to files being open on the server at the time the user is attempting to rename or move the folder. The following thread, albiet old, appears to have nailed the problem on the head http://arstechnica.com/civis/viewtopic.php?p=24558131. In particular, there appears to be file locking happening when preview is turned on through the finder. I've had all users remove preview from their Macs and this appears to have helped reduce the occurances of the password prompt, but has not completly solved the problem. This is also a work around, not a fix.
I've been using a series of command to help me trace the problem including openfile.exe on the Windows 2012 Storage Server (sharing the files via smb only) to discover who has what files open on the server, and the lsof command on the client workstations to discover what process has the file open. So far, the finder is consistently the only thing with the file open... even with the finder preview turned off. I've also found that the "open file" is simply the fact that the offending users Mac has a finder window with just the folder open (none of the files within the folder or previews open).
Is the real solution to simply close all finder windows when you're done working in a folder, or is there more that anyone can think of to help me find out exactly what is holding the file lock? Is this a known bug in the SMB implementation of ML? Can we expect to see a fix with Mavericks which will now be using SMB2.0?
Any help or information anyone can provide would be greatly appreciated. I have a bunch of documentation on this issue and would be happy to share. Please let me know if anyone needs any additional details.

Hello all - many apologies for my delay in posting here; and Squiggle, thanks for the second-hand nudge. As Stephen said we have been testing a solution concerning a setting in Finder's view options for the last few months, and these seem to have solved the issue in hand.
Essentially, we found that Finder was holding files open whenever the 'Show Icon Preview' option was set, on any of the four folder views, on any client machine accessing the share. Below is a piece of documentation I wrote up for our Service desk explaining how to diagnose and manually fix this issue on the client:
        - In Finder, open any folder
        - Click on the cog icon and select 'show view options.' Check that, in the dialogue box which appears, the 'Show icon preview' box is not checked. Click the other three Finder views and check it's turned off here too.
        - Click 'Use as Defaults'
In order to make this change remotely on multiple machines, you will need to change the clients' com.apple.plist files, and set every instance of the <showIconPreview> key to <False>. This is nested within several key / dictionary pairs in com.apple.finder.plist, once under <standardViewOptions> and thrice within <standardViewSettings>. As Stephen has already mentioned, the fact that this key is nestled deep within compound dictionaries seems to render them untouchable by defaults, though I would be very happy to be corrected on this.
How you push this change out will depend on your management system. We had been using Casper to
to create a managed preference pertaining to <standardViewOptions> and <standardViewSettings> within com.apple.finder.plist. These contained as values the entire dictionary associated with these keys, with the value for each <showIconPreview> set to false. This was then applied at a User Enforced Level (running every logon after Finder has set up the system defaults).
As a side note, I have found that certain machines (Such as the 10.8.3 machine I'm working on now) contain a key named <FK_StandardViewSettings>, which I have been unable to ascertain the purpose or origination of. These don't seem to affect the fix, so we've left them alone.
Irritatingly, Casper has dropped support for custom Managed Preferences in their latest release, so this problem has now resurfaced. I will keep this page updated with any fixes or workarounds I find.
Hope that helps,
Josh Smith

Help! File locking/multi-thread/instance problem!

Hi,
I have a program which runs multiple threads and they call a seperate java class to write information to a file. However because there are many threads some of the information sometimes gets lost. Unfortunately I am restricted to Java 1.1 so cannot use file locking. Does anybody know of an effective way of locking files before Java 1.4?
Alternatively it would be just as useful if only one instance of the writer class existed to write to files. Therefore is it possible for different programs/threads calling this writer class to share one instance of it so only one writer program is active thus preventing the loss of information that happens when multiple instances try to write to the same file.
Any help would be very much appreciated,
Thanks
Paul

Alternatively it would be just as useful if only one
instance of the writer class existed to write to files.
Therefore is it possible for different programs/threads
calling this writer class to share one instance of it so
only one writer program is active thus preventing the
loss of information that happens when multiple
instances try to write to the same file.This is a very good idea. Or you can implement a static method write. This, combined with syncr. will give you exactly what you need: a lock not on the file but on the writer to the file.

Report File Handle Release

Hello All,
I have a client that are using Crystal Reports embeded in their java web. They have stated that each time a report is run, a file handle is open and stays open for the rpt file.
Has anyone has any experience with forcing java to release the rpt file handle?
Thanks,
Clark

Thanks for the response.
They are in a IBM Java RAD environment using Crystal v11 which is embedded with the suite.    I sent them the following snippet to release the file.    This should work right?
     //Release report.
     reportClientDoc.close();
Clark

Force a DHCP release / renew on ASA from CLI

Hi forum,
Is it possible to force an ASA to release and/or renew a DHCP lease? To be clear, the ASA is a DHCP client in this case, getting its IP address from an ISP on an external interface. I couldn't seem to find anything in the docs for this function, which seems like a pretty basic thing to want to do. I saw some references to doing this through ADSM, but nothing from the CLI. This is an ASA5505 running 8.2(2) if that matters.
Thanks in advance!

But specifically when I delete the "ip address", does that cause a DHCP release?
The scenario I'm interested in is if I'm using the ASA as a router for my ISP, but I want to switch to a different router (i.e. not the ASA). My ISP will not provide a new DHCP address until the current one is released (or the lease expires, or you call into tech support to manually release the address). I'd like to be able to force the ASA to release the address, but not necessarily renew it with the ASA.
Thanks in advance...

Really persistent file lock

I've got a problem where connections with certain file locks do not seem to close for more then a day even on reboot / shutdown of the client.
We have a .net/C# based document processor that runs on every user session that requires it that manages to put some weird file lock on its log files that are located on users home directory's (unable to change that).
For some reason our OES11 server every now and then does not close the connection holding the log file open and users can not start the processor in the morning because it can not access its own log file.
This -occasionally- happens with normal workstations running XP but more frequently on Win2k8r2 with Xenapp although all our Xenapp servers get rebooted daily.
I would expect the OES server closing the connections upon reboot of the Xenapp servers or when the workstation is turned off for 10+ hours. It would appear it takes somewhere over 24 hours for the connection / lock to clear but I have nothing to back this up.
Can anybody explain this behaviour and/or come up with possible workarounds, I always assumed connections were actively checked to see if they were alive.
I also need to have a talk with the people where this amazing piece of .NET software came from about the way they lock files.
Thanks

In article <[email protected]>, Conz wrote:
> For some reason our OES11 server every now and then does not close the
> connection holding the log file open and users can not start the
> processor in the morning because it can not access its own log file.
>
The default watchdog timeout process isn't as effective as it used to be
on NetWare, but there are things you can do. I had hit it with OES2 and
mostly resolved with http://www.novell.com/support/kb/doc.php?id=7004848
and while looking for that TID found this useful looking one.
http://www.novell.com/support/kb/doc.php?id=3138614
Andy Konecny
Knowledge Partner (voluntary SysOp)
KonecnyConsulting.ca in Toronto
Andy's Profile: http://forums.novell.com/member.php?userid=75037

No file lock?

Hi all. We have a few users of Photoshop (several versions, but mostly CS3). The issue we are having is that two users were working on the same file at the same time and overwrote each other's work. I was skeptical at first. But, sure enough, they demonstrated to me that a file already opened can be opened by another user will full write permissions. This does not seem right to me. Shouldn't there be a lock file automatically created when the first user opens the file?

function(){return A.apply(null,[this].concat($A(arguments)))}
VirtualTraveler wrote:
Very simple, easy to implement, tremendously valuable if it prevents work from being lost. Agree?
While a simple file locking scheme could be helpful, it is but a small part of a larger problem: That of coordinating the collaboration of a number of people who access the same data.
That's why I mentioned Subversion. It provides such functionality.
Using it goes something like this:
1. User A needs to work on file X.
2. Using Explorer, user A right clicks on the file or one of the parent folders on their computer and chooses Update, to ensure he/she has all the latest changes from others.
3. The Update completes in a few seconds, incrementally retrieving the latest files from the central Subversion server to User A's computer.
4. User A right-clicks on the file and chooses "Get Lock" from the Subversion menu and enters the reason.
5. User A opens and works on the file, which is on his/her computer and saves it there.
6. User B goes through steps 1 through 4, but 4 returns an error stating that "file is already locked by User A".
7. User B contacts User A and they agree to coordinate their work.
8. User A saves his/her changes, and commits the file back into Subversion, releasing the lock.
9. User B is now able to complete step 4 and continues with his/her work.
Using such a system is pretty standard practice in organizations where multiple people must access the same data in a coordinated way to do their work.
-Noel

File locking in AIR?

Hello everyone. Is there some sort of file locking supported
in AIR? I need to lock a file for concurrency issues.
Thanks in advance.

Is there any possibility you can do your concurrency through
the embedded SQLite database? One program writes data meant for
another program, which reads it out and acts on it. SQLite handles
concurrency using the platform's native file locking
procedures.

Possible to force file lock release?

Similar Messages

Maybe you are looking for