Is it possible to "close" an open file on the server? Let me explain it: when my nlm is trying to update a file, but other people has it opened, I'm clearing those connections using NWClearConnectionNumber, which in turn closes those open file handles on the server. It would be nice to do the same without the need to clear the entire connection, to minimize the impact on the user's current work.
I've not come across such an interface, but even if it does exist the results will be the same, a user working with say word file is likely to lose all their work if either the connection or just the file handle is disconnected at the server.
> Is it possible to "close" an open file on the server? Let me explain it: when my nlm is trying to update a file, but > other people has it opened, I'm clearing those connections using NWClearConnectionNumber, which in turn closes those > open file handles on the server. It would be nice to do the same without the need to clear the entire connection, to > minimize the impact on the user's current work.
> I've not come across such an interface, but even if it does exist the > results will be the same, a user working with say word file is likely to > lose all their work if either the connection or just the file handle is > disconnected at the server.
but: if the user has also Excel and Access open files, these are also affected when you kill the whole connection - I think this is what Gyorgy wants to avoid....
>>I've not come across such an interface, but even if it does exist the >>results will be the same, a user working with say word file is likely to >>lose all their work if either the connection or just the file handle is >>disconnected at the server.
> but: if the user has also Excel and Access open files, these are also > affected when you kill the whole connection - I think this is what Gyorgy > wants to avoid....
Yeah, exactly. I'd like to keep all other applications working, by breaking only that single app which has the file opened. I could even imagine a more sophisticated app being able to intelligently handle this situation, eg. by allowing to save the work under a different file name.
> Yeah, exactly. I'd like to keep all other applications working, by > breaking only that single app which has the file opened. I could even > imagine a more sophisticated app being able to intelligently handle this > situation, eg. by allowing to save the work under a different file name.
hmmm, but since the server itself must do something like looping through all open files of a given connection if we kill it there must exist something at least at server side (perhaps no xplat) which can force closing a file.... where are the hot tips of some undeocumented functions? Just someone else asked in another forum for exactly the same - and BTW. I also had already some situations where this would have helped a lot.... so lets make a request for a new function: NWCloseFileForced() or such....
>>> I've not come across such an interface, but even if it does exist the >>> results will be the same, a user working with say word file is likely to >>> lose all their work if either the connection or just the file handle is >>> disconnected at the server.
>> but: if the user has also Excel and Access open files, these are also >> affected when you kill the whole connection - I think this is what >> Gyorgy wants to avoid....
> Yeah, exactly. I'd like to keep all other applications working, by > breaking only that single app which has the file opened. I could even > imagine a more sophisticated app being able to intelligently handle this > situation, eg. by allowing to save the work under a different file name.
This can be done. You can do it with NoRM and MONITOR I believe. FWIW, I wrote a method that allows NSS to expose handles to another application and that application can then close the handle with prejudice. I'm pretty sure it's not published and I'm not about to publish it so broadly but, in essence it is this pseudo-code:
Impersonate a connection Iterate file handles If current file handle is the one to kill Close file handle and break Repeat Profit
My comment was more about the fact that any solution would break something. Novell seems to have a strong policy only not directly providing interfaces that can cause 'damage' to the environment. Saying that it looks like David has put forward a solution.
> >>I've not come across such an interface, but even if it does exist the > >>results will be the same, a user working with say word file is likely to > >>lose all their work if either the connection or just the file handle is > >>disconnected at the server.
> > but: if the user has also Excel and Access open files, these are also > > affected when you kill the whole connection - I think this is what Gyorgy > > wants to avoid....
> Yeah, exactly. I'd like to keep all other applications working, by breaking only that single app which has the file > opened. I could even imagine a more sophisticated app being able to intelligently handle this situation, eg. by allowing > to save the work under a different file name.
> My comment was more about the fact that any solution would break > something. Novell seems to have a strong policy only not directly > providing interfaces that can cause 'damage' to the environment. Saying > that it looks like David has put forward a solution.
I couldn't possibly comment...and I was never here.
>>>>I've not come across such an interface, but even if it does exist the >>>>results will be the same, a user working with say word file is likely to >>>>lose all their work if either the connection or just the file handle is >>>>disconnected at the server.
>>>but: if the user has also Excel and Access open files, these are also >>>affected when you kill the whole connection - I think this is what Gyorgy >>>wants to avoid....
>>Yeah, exactly. I'd like to keep all other applications working, by breaking only that single app which has the file >>opened. I could even imagine a more sophisticated app being able to intelligently handle this situation, eg. by
> My comment was more about the fact that any solution would break > something. Novell seems to have a strong policy only not directly > providing interfaces that can cause 'damage' to the environment. Saying > that it looks like David has put forward a solution.
hehe - then they should take my view of things where a corrupt application writes endlessly into a file, my NLM at the server even detects that it goes bolow min vol limit, and cant close that file without having to close whole connection....
I remember in the long and distance Novell being attacked for providing 'useful' tools such as the one you are doing. The difference between yourself and Novell is that you will have a targeted and maybe educated market, while Novell ends up with the problems caused by 2 many sys-admin staff just enabling the feature without understanding it correctly. After all one person's corrupt application is another person's auditing tool :)
> > My comment was more about the fact that any solution would break > > something. Novell seems to have a strong policy only not directly > > providing interfaces that can cause 'damage' to the environment. Saying > > that it looks like David has put forward a solution. > hehe - then they should take my view of things where a corrupt application > writes endlessly into a file, my NLM at the server even detects that it goes > bolow min vol limit, and cant close that file without having to close whole > connection....
> >>> I've not come across such an interface, but even if it does exist the > >>> results will be the same, a user working with say word file is likely to > >>> lose all their work if either the connection or just the file handle is > >>> disconnected at the server.
> >> but: if the user has also Excel and Access open files, these are also > >> affected when you kill the whole connection - I think this is what > >> Gyorgy wants to avoid....
> > Yeah, exactly. I'd like to keep all other applications working, by > > breaking only that single app which has the file opened. I could even > > imagine a more sophisticated app being able to intelligently handle this > > situation, eg. by allowing to save the work under a different file name. > This can be done. You can do it with NoRM and MONITOR I believe. FWIW, I > wrote a method that allows NSS to expose handles to another application > and that application can then close the handle with prejudice. I'm > pretty sure it's not published and I'm not about to publish it so > broadly but, in essence it is this pseudo-code: > Impersonate a connection > Iterate file handles > If current file handle is the one to kill > Close file handle and break > Repeat > Profit
Hi,
Can I have the code for this pseudo-code?? I need to develop an application for my organisation for close a file for graduate an application.
