how to get the owner and time information of a file in the UNIX?

[jojo]

hi,

I wanna get the detailed file information , such as owner, time in the
UNIX system. how to implement it in Java? thanks

 

[Roedy Green]

I wanna get the detailed file information , such as owner, time in the
UNIX system. how to implement it in Java? thanks

Time you get with File.last Modified. There are a few other bits of
info you can get. See http://mindprod.com/jgloss/file.html

For the rest, you will need to write some JNI. Basically you write a
program in C/C++ to get what you want and pass it back to Java.

See http://mindprod.com/jgloss/jni.html

 

[Luke]

Time you get with File.last Modified. There are a few other bits of
info you can get. See http://mindprod.com/jgloss/file.html

For the rest, you will need to write some JNI. Basically you write a
program in C/C++ to get what you want and pass it back to Java.

See http://mindprod.com/jgloss/jni.html

If you didn't want to resort to JNI and C/C++ code, you could probably
use Runtime.exec() to issue the unix ls command, then capture and parse
the output. This isn't going to be very portable, but then neither is
JNI.

 

[Roedy Green]

If you didn't want to resort to JNI and C/C++ code, you could probably
use Runtime.exec() to issue the unix ls command, then capture and parse
the output. This isn't going to be very portable, but then neither is
JNI.

At least with JNI and JAWS it is possible to implement the same native
class on various platforms. JAWS automatically selects the correct
version. Your code stays constant. With the exec method, you need to
cook something up different for each platform in the application.
Further there is a big overhead for an exec that is often intolerable
for something you want to call thousands of times.

 

[Hemal Pandya]

hi,

I wanna get the detailed file information , such as owner, time in the
UNIX system. how to implement it in Java? thanks

http://pandonia.canberra.edu.au/java/posix/
http://www.basepath.com/aup/jtux/

There might be more. Search for java+posix

 

[Luke]

At least with JNI and JAWS it is possible to implement the same native
class on various platforms. JAWS automatically selects the correct
version. Your code stays constant. With the exec method, you need to
cook something up different for each platform in the application.
Further there is a big overhead for an exec that is often intolerable
for something you want to call thousands of times.

I'm not familiar with JAWS, but it sounds like you're saying that with
JNI/JAWS the application stays constant and you reimplement the c/c++
code on each platform, where with the exec method you'd need to
reimplement the application class on each platform.

One way to minimize overhead with the exec method is to keep the process
running instead of starting up a new process for each call. The process
might initially start a unix shell (like bash) and then each call would
simply pass a unix command to the process and parse the output.

 

[Gordon Beaton]

One way to minimize overhead with the exec method is to keep the
process running instead of starting up a new process for each call.
The process might initially start a unix shell (like bash) and then
each call would simply pass a unix command to the process and parse
the output.

How is using an additional process to create a new process for each
command on your behalf (and keeping it around even when it's not
needed), using less resources than just creating each new process
yourself?

/gordon

 

[Joan]

hi,

I wanna get the detailed file information , such as owner, time
in the
UNIX system. how to implement it in Java? thanks

Use run and the command "ls -l <filename>"

 

[Luke]

How is using an additional process to create a new process for each
command on your behalf (and keeping it around even when it's not
needed), using less resources than just creating each new process
yourself?

/gordon

Suppose I want to execute the 'ls' command 100 times. I could create
100 processes to do this:

for (int i = 0; i < 100; i++)
{
create a new process and issue the 'ls' command
}

Or I could create one long running process,

Process P = create a new process

for (int i = 0; i < 100; i++)
{
use P to issue the 'ls' command
}

In the first example I've created 100 processes, while in the second
I've only created one process. Doesn't that reduce overhead
significantly?

 

[Chris Head]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Luke wrote:
[snip]

Suppose I want to execute the 'ls' command 100 times. I could create
100 processes to do this:

for (int i = 0; i < 100; i++)
{
create a new process and issue the 'ls' command
}

Or I could create one long running process,

Process P = create a new process

for (int i = 0; i < 100; i++)
{
use P to issue the 'ls' command
}

In the first example I've created 100 processes, while in the second
I've only created one process. Doesn't that reduce overhead
significantly?

Greetings,
No. Overhead is NOT reduced because, on Linux and I think most other
UNIX systems, "ls" is a program. Every time you type "ls" at a command
prompt, you are starting another process. The only difference between
your examples is WHO is creating the new process, NOT whether or not a
new process is being created.

$ which ls
/bin/ls

Chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (MingW32)

iD8DBQFDI8jQ6ZGQ8LKA8nwRAghBAJsGFLeuBh2nYvVo1vwugIr053AcpwCgw9tQ
GMO4tMT38HqBuqcMOKVcHnI=
=vX1H
-----END PGP SIGNATURE-----

 

[Gordon Beaton]

In the first example I've created 100 processes, while in the second
I've only created one process. Doesn't that reduce overhead
significantly?

In the second example, *you* create one process, and *it* creates an
additional 100 processes. Last I checked, that's one *additional*
process.

/gordon

 

[Roedy Green]

I'm not familiar with JAWS, but it sounds like you're saying that with
JNI/JAWS the application stays constant and you reimplement the c/c++
code on each platform, where with the exec method you'd need to
reimplement the application class on each platform.

Yes. JAWS=Java Web Start http://mindprod.com/jgloss/javawebstart.html

Your JNLP file tells it what native class implementations you have
available. It only downloads the appropriate one.

You would have something like this in your JNLP file:

<!-- JNI native Sun .so code -->
<resources os="SunOS" arch="sparc">
<nativelib href="lib/solaris/corelibs.jar"/>
</resources>

<!-- JNI native Windows .dll code -->
<resources os="Windows" arch="x86">
<nativelib href="lib/windows/corelibs.jar"/>
</resources>

You write your Java source as if you were dealing with only one
platform. When you say:

System.loadLibrary("myJniClass");

that will go looking in lib/solaris/corelibs.jar on SunOS for
myJniClass.so and for lib/windows/corelibs.jar on Windows for
myJniClass.dll.

They did it right. JAWS is an underrated product.

 

[Roedy Green]

In Windows, if you wanted to take advantage of the 4NT for loop
cleverness and built in functions such as eval. There are no external
programs associated with these other than the 4NT.exe command
processor itself.

I you fire up a new command processor for each instance, you will have
considerably more overhead than if you fire up one instance and feed
it your list of commands to do.

It is often hard to tell which commands are internal. You have to
search the disk for the corresponding executable to find out.

 

[Joan]

Greetings,
No. Overhead is NOT reduced because, on Linux and I think most
other
UNIX systems, "ls" is a program. Every time you type "ls" at a
command
prompt, you are starting another process. The only difference
between
your examples is WHO is creating the new process, NOT whether
or not a
new process is being created.

I haven't used UNIX in a while, but there is a thing called
"sticky bit" that will
keep the process running when it is set so that multiple users
share the
same copy. No new process generation needed. No tricky loops
either.
Just normal use.

 

[Oliver Wong]

I haven't used UNIX in a while, but there is a thing called "sticky bit"
that will
keep the process running when it is set so that multiple users share the
same copy. No new process generation needed. No tricky loops either.
Just normal use.

I'm not much of a UNIX guru, but I thought the Sticky bit meant that
when the program is run, it's run under the owner's permission (and not
under the invoker's permission).

- Oliver

 

[Joan]

I'm not much of a UNIX guru, but I thought the Sticky bit
meant that when the program is run, it's run under the owner's
permission (and not under the invoker's permission).

- Oliver

From the web:

sticky bit on regular files
===========================
[From chmod(2)]
If an executable file is prepared for sharing, mode bit S_ISVTX
prevents
the system from abandoning the swap-space image of the
program-text
portion of the file when its last user terminates. Then, when
the next
user of the file executes it, the text need not be read from the
file
system but can simply be swapped in, thus saving time.

 

[Gordon Beaton]

sticky bit on regular files
===========================
[From chmod(2)]
If an executable file is prepared for sharing, mode bit S_ISVTX
prevents the system from abandoning the swap-space image of the
program-text portion of the file when its last user terminates.
Then, when the next user of the file executes it, the text need not
be read from the file system but can simply be swapped in, thus
saving time.

It is normal for all instances of a running program to share the
read-only text (i.e. code) segment, regardless of the sticky bit.

Also regardless of the sticky bit, a new process is created each time
the program is run.

What you have described is simply a mechanism used by the OS to avoid
having to re-read the program from disk each time it's run.

/gordon

 

[Chris Uppal]

I'm not much of a UNIX guru, but I thought the Sticky bit meant that
when the program is run, it's run under the owner's permission (and not
under the invoker's permission).

You are thinking of the "suid" (set effective user ID) bit; the sticky bit
(which I suspect is not used any more) means something else -- as Joan has
already explained.

-- chris

 

[Kenneth Patrick Turvey]

You are thinking of the "suid" (set effective user ID) bit; the sticky bit
(which I suspect is not used any more) means something else -- as Joan has
already explained.

It is still used on directories. On executable files it is typically
ignored.

 

[blmblm]

It is still used on directories. On executable files it is typically
ignored.

Ignored for executables on many systems (Linux being the example it's
easy for me to check). Used on directories (again in some systems),
but for a different purpose. From the man page for chmod on my Linux
box:

On older Unix systems, the sticky bit caused executable
files to be hoarded in swap space. This feature is not useful
on modern VM systems, and the Linux kernel ignores the
sticky bit on files. Other kernels may use the sticky bit
on files for system-defined purposes. On some systems,
only the superuser can set the sticky bit on files.

When the sticky bit is set on a directory, files in that
directory may be unlinked or renamed only by root or their
owner. Without the sticky bit, anyone able to write to
the directory can delete or rename files. The sticky bit
is commonly found on directories, such as /tmp, that are
world-writable.