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

Discussion in 'Java' started by jojo, Sep 9, 2005.

  1. jojo

    jojo Guest

    hi,

    I wanna get the detailed file information , such as owner, time in the
    UNIX system. how to implement it in Java? thanks
     
    jojo, Sep 9, 2005
    #1
    1. Advertising

  2. jojo

    Roedy Green Guest

    On 8 Sep 2005 16:31:57 -0700, "jojo" <> wrote or
    quoted :

    >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
    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Again taking new Java programming contracts.
     
    Roedy Green, Sep 9, 2005
    #2
    1. Advertising

  3. jojo

    Luke Guest

    In article <>,
    Roedy Green <> wrote:

    > On 8 Sep 2005 16:31:57 -0700, "jojo" <> wrote or
    > quoted :
    >
    > >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


    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.
     
    Luke, Sep 9, 2005
    #3
  4. jojo

    Roedy Green Guest

    On Thu, 08 Sep 2005 20:46:07 -0500, Luke <> wrote or
    quoted :

    >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.
    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Again taking new Java programming contracts.
     
    Roedy Green, Sep 9, 2005
    #4
  5. jojo

    Hemal Pandya Guest

    Hemal Pandya, Sep 9, 2005
    #5
  6. jojo

    Luke Guest

    In article <>,
    Roedy Green <> wrote:

    > On Thu, 08 Sep 2005 20:46:07 -0500, Luke <> wrote or
    > quoted :
    >
    > >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.


    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.
     
    Luke, Sep 10, 2005
    #6
  7. On Sat, 10 Sep 2005 03:31:59 -0500, Luke wrote:
    > 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

    --
    [ do not email me copies of your followups ]
    g o r d o n + n e w s @ b a l d e r 1 3 . s e
     
    Gordon Beaton, Sep 10, 2005
    #7
  8. jojo

    Joan Guest

    "jojo" <> wrote in message
    news:...
    > 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>"
     
    Joan, Sep 10, 2005
    #8
  9. jojo

    Luke Guest

    In article <43229f87$>, Gordon Beaton <>
    wrote:

    > On Sat, 10 Sep 2005 03:31:59 -0500, Luke wrote:
    > > 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


    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?
     
    Luke, Sep 10, 2005
    #9
  10. jojo

    Chris Head Guest

    -----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-----
     
    Chris Head, Sep 11, 2005
    #10
  11. On Sat, 10 Sep 2005 17:42:21 -0500, Luke wrote:
    > 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

    --
    [ do not email me copies of your followups ]
    g o r d o n + n e w s @ b a l d e r 1 3 . s e
     
    Gordon Beaton, Sep 11, 2005
    #11
  12. jojo

    Roedy Green Guest

    On Sat, 10 Sep 2005 03:31:59 -0500, Luke <> wrote or
    quoted :

    >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.

    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Again taking new Java programming contracts.
     
    Roedy Green, Sep 11, 2005
    #12
  13. jojo

    Roedy Green Guest

    On Sat, 10 Sep 2005 17:42:21 -0500, Luke <> wrote or
    quoted :

    >


    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.
    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Again taking new Java programming contracts.
     
    Roedy Green, Sep 11, 2005
    #13
  14. jojo

    Joan Guest

    <snip>
    > 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.
     
    Joan, Sep 12, 2005
    #14
  15. jojo

    Oliver Wong Guest

    "Joan" <> wrote in message
    news:...
    > 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
     
    Oliver Wong, Sep 12, 2005
    #15
  16. jojo

    Joan Guest

    "Oliver Wong" <> wrote in message
    news:H_lVe.236994$HI.37983@edtnps84...
    > "Joan" <> wrote in message
    > news:...
    >> 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


    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.
     
    Joan, Sep 13, 2005
    #16
  17. On Mon, 12 Sep 2005 19:00:41 -0500, Joan wrote:
    > 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

    --
    [ do not email me copies of your followups ]
    g o r d o n + n e w s @ b a l d e r 1 3 . s e
     
    Gordon Beaton, Sep 13, 2005
    #17
  18. jojo

    Chris Uppal Guest

    Oliver Wong wrote:

    > 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
     
    Chris Uppal, Sep 13, 2005
    #18
  19. On Tue, 13 Sep 2005 08:01:59 +0100, Chris Uppal wrote:
    > 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.

    --
    Kenneth P. Turvey <>
    http://kt.squeakydolphin.com (not much there yet)
    Jabber IM:
    Phone: (314) 255-2199
     
    Kenneth Patrick Turvey, Sep 13, 2005
    #19
  20. jojo

    Guest

    In article <>,
    Kenneth Patrick Turvey <> wrote:
    >On Tue, 13 Sep 2005 08:01:59 +0100, Chris Uppal wrote:
    >> 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.


    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.

    --
    | B. L. Massingill
    | ObDisclaimer: I don't speak for my employers; they return the favor.
     
    , Sep 13, 2005
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. kai rosenthal

    Windows: get owner and group of a file

    kai rosenthal, Dec 6, 2006, in forum: Python
    Replies:
    6
    Views:
    687
  2. Thibault Ketterer

    Get file owner in Windows

    Thibault Ketterer, Jul 23, 2007, in forum: Python
    Replies:
    0
    Views:
    365
    Thibault Ketterer
    Jul 23, 2007
  3. John Fry

    get username of file owner?

    John Fry, Jun 10, 2005, in forum: Ruby
    Replies:
    1
    Views:
    136
    Fredrik Fornwall
    Jun 10, 2005
  4. Charles Heizer

    Get Owner of a file

    Charles Heizer, Jul 21, 2008, in forum: Ruby
    Replies:
    3
    Views:
    165
    Marcelo
    Jul 21, 2008
  5. Whitney
    Replies:
    1
    Views:
    137
    Thomas 'PointedEars' Lahn
    Aug 3, 2004
Loading...

Share This Page