[jcifs] Proposal to enhance SmbFile.getInputStream and getOutputStream methods
Michael B Allen
ioplex at gmail.com
Tue Dec 21 22:39:26 MST 2010
I would say that if going through SmbFile to set shareAccess works,
that is the way to do it. I do not see why that is "not as elegant".
Supplying shareAccess is somewhat unusual. I would rather not clutter
the API with extra constructors for infrequently traveled code paths.
On Tue, Dec 21, 2010 at 9:18 AM, Sai Pullabhotla
<sai.pullabhotla at jmethods.com> wrote:
> Thought I should post this to the group and get some feedback. Below
> is what I need in my application.
> I will be reading and writing several files on a share. When I read a
> file, I need to ensure I acquire a Shared Read Lock, and when I'm
> writing to a file, I need to acquire an exclusive lock (NO other
> process should be able to open the file for anything).
> My code, for various reasons cannot use the SmbRandomAccessFile, and
> only calls SmbFile.getInputStream and getOutStream methods. It would
> be nice to overload these methods to indicate the desired shareAccess
> (or locking mode). Currently, it appears that you have to create an
> SmbFile object with the correct shareAccess or else you cannot enforce
> any specific shareAccess. This might work, but when we create SmbFile
> object, we will not know if the file is being created for reading or
> writing and what kind of locks we need. Currently when I've to
> read/write a file, I've to create a new SmbFile that is same as the
> one I already have on hand using - new SmbFile(mySmbFile, "",
> shareAccess). This seems to be working alright, but thought it is not
> as elegant.
> Please let me know if you think it would be a good idea to add a
> couple more overloaded methods to SmbFile. I can submit a patch if you
> are in favor.
Michael B Allen
Java Active Directory Integration
More information about the jCIFS