file.exists() timeout?

Hi

Windows 2003 Server, JDK 1.5.0_09

I have a servlet that is trying to access a .jpg file located on
another server. The servlet builds a file object and uses the .exists()
method to check that its got a valid path/filename and then constructs
a FileInputStream to read the data. Although I know its got a valid UNC
path exists() returns false. I've even tried mounting the remote
directory to the server and hardcoding the path, but still no joy.

Removing the exists() test and opening the FileInputStream also fails
to return the data

Because of some routing issues (yet to be resolved) the connection to
the remote server is extremely slow. the same servlet running on a
server on a different segment of the network with a better connection
speed works as expected, so I was wondering if there's a timeout issue
with accessing remote files and, if so, how do I change this.

Is there any other reason why file.exists() would fail to find a file
that Windows can find?

Regards
Roger

Gilbert Ostlethwaite

On Jan 26, 3:41 am, "Gilbert Ostlethwaite"
<roger.var...@googlemail.com> wrote:
...
> I have a servlet that is trying to access a .jpg file located on
> another server. ..
(snip)

Can you produce an URL for that JPG?
(I do not quite get all this talk about files.)

Andrew T.

Gilbert Ostlethwaite wrote:

> Is there any other reason why file.exists() would fail to find a file
> that Windows can find?

E.g. the Java-process is running with a different user than
the one you use for testing. Happens very often when installing
a java application as service. By default this service is
installed as "local user" so the user is not allowed to access
ressources like a SMB-share.

AFAIK the exists-method of java.io.File is just doing a native
call and without looking into the C-sources I assume that it's
just calling the corresponding Windows-API-call.


Regards, Lothar
--
Lothar Kimmeringer E-Mail:
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!

"Andrew Thompson" <> wrote in message
news: ups.com...
> On Jan 26, 3:41 am, "Gilbert Ostlethwaite"
> <roger.var...@googlemail.com> wrote:
> ..
>> I have a servlet that is trying to access a .jpg file located on
>> another server. ..
> (snip)
>
> Can you produce an URL for that JPG?
> (I do not quite get all this talk about files.)

I don't think the problem has anything to do with the contents of the
file being accessed. Windows allows you to specify filenames that refer to
files that exists on remote machines on a LAN (e.g. instead of
"C:\myDirectory\myFile.txt", you could use
\\remoteComputerName\remoteDirectory\remoteFile.tx t) and the OS is supposed
to abstract any special handling that remote file access might have in
comparison to local file handling (i.e. as a programmer, you don't need to
make your Windows programming "network aware" -- as long as you use MS's
file handling API, it's all support automatically for you).

I'm a bit fuzzy about this part of the OP's probelm description, but it
sounds like the computer the Java application is running on can access the
file just fine (when using Windows Explorer, for example), but the Java
application itself is unable to access the file, and the OP suspects the
problem might have something to do with timing-out, as the LAN connection is
apparently very slow.

- Oliver

> Is there any other reason why file.exists() would fail to find a file
> that Windows can find?

Maybe the "\" are not escaped to "\\".

ex. "\\server\dir\file" to "\\\\server\\dir\\file"

Bye.
--
Real Gagnon from Quebec, Canada
* Looking for Java or PB code examples ? Visit Real's How-to
* http://www.rgagnon.com/howto.html

> > Is there any other reason why file.exists() would fail to find a file
> > that Windows can find?E.g. the Java-process is running with a different user than
> the one you use for testing. Happens very often when installing
> a java application as service. By default this service is
> installed as "local user" so the user is not allowed to access
> ressources like a SMB-share.
>
> AFAIK the exists-method of java.io.File is just doing a native
> call and without looking into the C-sources I assume that it's
> just calling the corresponding Windows-API-call.
>

There may be something in this. Further testing shows that my servlet
can create and read a File() object, when the physical file is located
on the same physical server that the servlet is running on. However, if
the file is located on a different server then my servlet cannot read
the file regardless whether I use a UNC path or mount the remote drive
directly via Windows Explorer.

This is using Suns JDK 1.5.0_09 on a Windows 2003 SP1 server. The file
that I'm trying to read is also on a Windows 2003 SP1 server. If I drop
back to Suns JDK 1.4.2_13 then everything works as expected.


Regards
Roger

On 25 Jan, 17:56, "Andrew Thompson" <andrewtho...@gmail.com> wrote:
> On Jan 26, 3:41 am, "Gilbert Ostlethwaite"<roger.var...@googlemail.com> wrote:..> I have a servlet that is trying to access a .jpg file located on
> > another server. ..(snip)
>
> Can you produce an URL for that JPG?
> (I do not quite get all this talk about files.)
>

The servlet on server A is acting like a proxy by reading a File()
object that points to a .jpg file located on Server B and sending the
contents of the FileInputStream() to the client.

Regards
Roger

"Gilbert Ostlethwaite" <> wrote in message
news: oups.com...
>
>> > Is there any other reason why file.exists() would fail to find a file
>> > that Windows can find?E.g. the Java-process is running with a different
>> > user than
>> the one you use for testing. Happens very often when installing
>> a java application as service. By default this service is
>> installed as "local user" so the user is not allowed to access
>> ressources like a SMB-share.
>>
>> AFAIK the exists-method of java.io.File is just doing a native
>> call and without looking into the C-sources I assume that it's
>> just calling the corresponding Windows-API-call.
>>
>
> There may be something in this. Further testing shows that my servlet
> can create and read a File() object, when the physical file is located
> on the same physical server that the servlet is running on. However, if
> the file is located on a different server then my servlet cannot read
> the file regardless whether I use a UNC path or mount the remote drive
> directly via Windows Explorer.
>
> This is using Suns JDK 1.5.0_09 on a Windows 2003 SP1 server. The file
> that I'm trying to read is also on a Windows 2003 SP1 server. If I drop
> back to Suns JDK 1.4.2_13 then everything works as expected.

Try producing an SSCCE that demonstrates the problem (preferably stand
alone application, instead of servlet, unless the problem only occurs in
servlets). http://mindprod.com/jgloss/sscce.html

If you can show the problem in a dozen lines of code, and show that it
works in 1.4, but not 1.5, you can probably file it as a regression bug to
Sun. Also, have you considered trying 1.6?

- Oliver

Gilbert Ostlethwaite wrote:

> There may be something in this. Further testing shows that my servlet
> can create and read a File() object, when the physical file is located
> on the same physical server that the servlet is running on. However, if
> the file is located on a different server then my servlet cannot read
> the file regardless whether I use a UNC path or mount the remote drive
> directly via Windows Explorer.

Again, in what type of server-process is the servlet running?
Is the server-process running as stand-alone process (i.e. there
is a user logged into Windows and the application is running
inside a window or the console) or as service (shown as entry
in the services-list).

If it's running as service, what user runs it (you can see
that if you look into the properties of the service, alter-
natively System.getProperty("user.name") should help as well)?

If it's running as local user, there is no way to get access
to files on the share or other remote ressource.


Regards, Lothar
--
Lothar Kimmeringer E-Mail:
PGP-encrypted mails preferred (Key-ID: 0x8BC3CD81)

Always remember: The answer is forty-two, there can only be wrong
questions!