You are viewing a plain text version of this content. The canonical link for it is here.

Posted to general@jakarta.apache.org by Goyo <go...@gmail.com> on 2011/03/21 10:52:57 UTC

Can't move files using symbolic links (allowLinking=true)

Hi.
I need to use a symbolic link to access a certain path in my server, where
I'm using Jakarta Tomcat 4.1.18.
We stablished a symbolic link to another path. At first, tomcat didn't see
this path through the symlink, but we searched for it and found the
allowLinking=true feature.
Now, it sees the path. However, and here comes the problem, it doesn't allow
to move files to this path.
We've tried to move files manually with the same user of tomcat and it works
well, but it doesn't via the web application. Besides, this feature worked
perfect before making this folder reachable through a symlink.

And we don't know what we have done wrong. Any help?

This is our config.xml:

       <Context path="/documents" docBase="/opt/rware/sgidoc/data" debug="0"
                 reloadable="true" crossContext="true">
                      <Resources
className="org.apache.naming.resources.FileDirContext"
                         allowLinking="true" />
        </Context>

        <Context path="/documents/temp" docBase="/opt/rware/my_app/pdf_mark"
debug="0"
                 reloadable="true" crossContext="true"/>

        <Context  path="/my_app" docBase="sgidoc"  debug="5"
reloadable="true" crossContext="true">
                <Resources
className="org.apache.naming.resources.FileDirContext"
                         allowLinking="true" />
                <Resource name="jdbc/YatskivBD" auth="Container"
type="javax.sql.DataSource"/>
                <ResourceParams name="jdbc/YatskivBD">
                <parameter>
                        <name>factory</name>

<value>org.apache.commons.dbcp.BasicDataSourceFactory</value>
                </parameter>
                <parameter>
                        <name>removeAbandonedTimeout</name>
                        <value>30</value>
                </parameter>
                <parameter>
                        <name>removeAbandoned</name>
                        <value>true</value>
                </parameter>
                <parameter>
                        <name>maxActive</name>
                        <value>20</value>
                </parameter>
                <parameter>
                        <name>maxIdle</name>
                        <value>-1</value>
                </parameter>
                <parameter>
                        <name>maxWait</name>
                        <value>10000</value>
                </parameter>
                <parameter>
                                <name>driverClassName</name>
                                <value>org.postgresql.Driver</value>
                </parameter>
                <parameter>
                                <name>url</name>
                                <value>jdbc:postgresql://
127.0.0.1:5432/my_app</value>
                </parameter>
                <parameter>
                                <name>username</name>
                                <value>user</value>
                </parameter>
                <parameter>
                                <name>password</name>
                                <value>pass</value>
                </parameter>

                </ResourceParams>


        </Context>

        <Context  path="/my_app_2" docBase="/home/my_app_2/webapp"
debug="5" reloadable="true" crossContext="true">
                <Resources
className="org.apache.naming.resources.FileDirContext"
                         allowLinking="true" />
                <Resource name="jdbc/YatskivBD" auth="Container"
type="javax.sql.DataSource"/>
                <ResourceParams name="jdbc/YatskivBD">
                <parameter>
                        <name>factory</name>

<value>org.apache.commons.dbcp.BasicDataSourceFactory</value>
                </parameter>
                <parameter>
                        <name>removeAbandonedTimeout</name>
                        <value>30</value>
                </parameter>
                <parameter>
                        <name>removeAbandoned</name>
                        <value>true</value>
                </parameter>
                <parameter>
                        <name>maxActive</name>
                        <value>20</value>
                </parameter>
                <parameter>
                        <name>maxIdle</name>
                        <value>-1</value>
                </parameter>
                <parameter>
                        <name>maxWait</name>
                        <value>10000</value>
                </parameter>
                <parameter>
                                <name>driverClassName</name>
                                <value>org.postgresql.Driver</value>
                </parameter>
                <parameter>
                                <name>url</name>
                                <value>jdbc:postgresql://
127.0.0.1:5432/my_app_2</value>
                </parameter>
                <parameter>
                                <name>username</name>
                                <value>user</value>
                </parameter>
                <parameter>
                                <name>password</name>
                                <value>pass</value>
                </parameter>

                </ResourceParams>

        </Context>

Re: Can't move files using symbolic links (allowLinking=true)

Posted by Peter Crowther <pe...@melandra.com>.

On 21 March 2011 17:36, Goyo <go...@gmail.com> wrote:
The (another) problem is that we can't access the source code :S

*chuckle* Gotta love configurable code.

OK, so the issue is that you're short of space.  How about mounting a
partition at origin/target?  Or even origin, depending how short of space
you are.  If you use loopback, the "partition"'s source doesn't even have to
be raw disk - it can be a file.

- Peter

Re: Can't move files using symbolic links (allowLinking=true)

Posted by Goyo <go...@gmail.com>.

The (another) problem is that we can't access the source code :S

2011/3/21 Peter Crowther <pe...@melandra.com>

> On 21 March 2011 16:35, Goyo <go...@gmail.com> wrote:
>
> > We want to move a file from origin/ to origin/target/
> > Previously, this movement was made perfect
> > Then, we change origin/target/ for a symlink called target which points
> to
> > another path in another partition.
> > Now, it doesn't move the file when using the server application (although
> > we
> > can do it manually from the filesystem using the same user of the tomcat
> > server).
> >
> > Can you change the server to move the file to origin/target/. ?  Sounds
> crazy, I know, but you'd be surprised how often referencing the directory
> that's the target of a symlink resolves such issues.
>
> - Peter
>

Re: Can't move files using symbolic links (allowLinking=true)

Posted by Peter Crowther <pe...@melandra.com>.

On 21 March 2011 16:35, Goyo <go...@gmail.com> wrote:

> We want to move a file from origin/ to origin/target/
> Previously, this movement was made perfect
> Then, we change origin/target/ for a symlink called target which points to
> another path in another partition.
> Now, it doesn't move the file when using the server application (although
> we
> can do it manually from the filesystem using the same user of the tomcat
> server).
>
> Can you change the server to move the file to origin/target/. ?  Sounds
crazy, I know, but you'd be surprised how often referencing the directory
that's the target of a symlink resolves such issues.

- Peter

Re: Can't move files using symbolic links (allowLinking=true)

Posted by Peter Crowther <pe...@melandra.com>.

On 22 March 2011 08:32, Goyo <go...@gmail.com> wrote:

> Inside "origin" there're about ten subdirs like "target". Some of them are
> symlinked to the new filesystem. The rest, must remain in their path so:
> - AFAIK, we can't mount the new drive to origin/target because target is
> not
> the only subdir we are symlinking (it is we should make more than one
> mount,
> one for every subdir we need to link.
> - We neither can make the symlink (or the mount) to the entire "origin"
> dir,
> because the client demands that only certain subdirs should be moved to the
> new drive.
>
> It seems there's no an easy way...
>
> Then you're screwed and so's the client.  Here are the conditions:

   1. You are not allowed to change or rewrite the C source code;
   2. The C source code uses rename(2) to move the file (it's worth checking
   this assumption);
   3. Rename(2) will not allow a file to be moved across filesystems;
   4. You are not allowed to configure partitions in such a way that all the
   files to be moved remain within the same filesystem after the move.

To solve the problem, you or the client will have to relax one of these
conditions.  The alternative is that the system keeps failing!

If we're correct about the technical restrictions in 1, 2 and 3, then your
(and the client's) only possibility to get a working system is to relax 4.

- Peter

Re: Can't move files using symbolic links (allowLinking=true)

Posted by Goyo <go...@gmail.com>.

Firstly, thanks for all your answers.

Inside "origin" there're about ten subdirs like "target". Some of them are
symlinked to the new filesystem. The rest, must remain in their path so:
- AFAIK, we can't mount the new drive to origin/target because target is not
the only subdir we are symlinking (it is we should make more than one mount,
one for every subdir we need to link.
- We neither can make the symlink (or the mount) to the entire "origin" dir,
because the client demands that only certain subdirs should be moved to the
new drive.

It seems there's no an easy way...



2011/3/22 Caldarale, Charles R <Ch...@unisys.com>

> > From: André Warnier [mailto:aw@ice-sa.com]
> > Subject: Re: Can't move files using symbolic links (allowLinking=true)
>
> > The perl documentation for rename() though, has this to say :
> > rename OLDNAME,NEWNAME
> >
> > perl itself being written in C, is usually pretty close to the C
> > library.  But maybe the above is a bit dated.
>
> No, the description is perfectly valid - for the rename function.
>
> > What I am getting at is : what if, for reasons of efficiency
> > (but not to the benefit of portability obviously) the developer
> > of this C application of which the OP does not have the source,
> > used a rename() call in order to move a file from one directory
> > to the other, instead of a copy-and-delete sequence ?
>
> Quite possible; as noted earlier, there is no move() API.  The C programmer
> has to understand the limitations of rename() and compensate for them where
> needed.  One could probably run strace to find out just what the program is
> doing.
>
>  - Chuck
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
> MATERIAL and is thus for use only by the intended recipient. If you received
> this in error, please contact the sender and delete the e-mail and its
> attachments from all computers.
>
>
> ---------------------------------------------------------------------
>  To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

RE: Can't move files using symbolic links (allowLinking=true)

Posted by "Caldarale, Charles R" <Ch...@unisys.com>.

> From: André Warnier [mailto:aw@ice-sa.com] 
> Subject: Re: Can't move files using symbolic links (allowLinking=true)

> The perl documentation for rename() though, has this to say :
> rename OLDNAME,NEWNAME
> 
> perl itself being written in C, is usually pretty close to the C 
> library.  But maybe the above is a bit dated.

No, the description is perfectly valid - for the rename function.

> What I am getting at is : what if, for reasons of efficiency 
> (but not to the benefit of portability obviously) the developer
> of this C application of which the OP does not have the source,
> used a rename() call in order to move a file from one directory
> to the other, instead of a copy-and-delete sequence ?

Quite possible; as noted earlier, there is no move() API.  The C programmer has to understand the limitations of rename() and compensate for them where needed.  One could probably run strace to find out just what the program is doing.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: Can't move files using symbolic links (allowLinking=true)

Posted by André Warnier <aw...@ice-sa.com>.

André Warnier wrote:
> Caldarale, Charles R wrote:
>>> From: peter.crowther3@googlemail.com 
>>> [mailto:peter.crowther3@googlemail.com] On Behalf Of Peter Crowther
>>> Subject: Re: Can't move files using symbolic links (allowLinking=true)
>>
>>>> Maybe a guess : under Unix/Linux, "move" (mv) is a "rename",
>>>> and it is not the same as "copy + delete original".  And a
>>>> "move" (rename) works as long as the source and target are
>>>> inside the same filesystem, but not if they are on different
>>>> filesystems.
>>
>>> Nice one André!  I'd completely missed that.
>>
>> Except... I have no problem issuing a shell mv command across 
>> filesystems; the shell recognizes that this is not just a simple 
>> rename() operation, and acts accordingly.  Note that there is no 
>> move() API (for filesystems); the concept is a figment of the shell's 
>> imagination.
>>
> And me thinking I'd had a brilliant insight.  There's always got to be 
> someone to spoil it..
> ;-)
> 
> The perl documentation for rename() though, has this to say :
> rename OLDNAME,NEWNAME
> 
>     Changes the name of a file; an existing file NEWNAME will be 
> clobbered. Returns true for success, false otherwise.
> 
>     Behavior of this function varies wildly depending on your system 
> implementation. For example, it will usually not work across file system 
> boundaries, even though the system mv command sometimes compensates for 
> this. Other restrictions include whether it works on directories, open 
> files, or pre-existing files. Check the perlport manpage and either the 
> rename(2) manpage or equivalent system documentation for details.
> 
> perl itself being written in C, is usually pretty close to the C 
> library.  But maybe the above is a bit dated.
> 

Well, maybe my idea had something to it anyway.  I find this :

14.7 Renaming Files

The rename function is used to change a file's name.

— Function: int rename (const char *oldname, const char *newname)

     The rename function renames the file oldname to newname. The file formerly accessible 
under the name oldname is afterwards accessible as newname instead. (If the file had any 
other names aside from oldname, it continues to have those names.)

     The directory containing the name newname must be on the same file system as the 
directory containing the name oldname.
...

Re: http://www.gnu.org/s/libc/manual/html_node/Renaming-Files.html


What I am getting at is : what if, for reasons of efficiency (but not to the benefit of 
portability obviously) the developer of this C application of which the OP does not have 
the source, used a rename() call in order to move a file from one directory to the other, 
instead of a copy-and-delete sequence ?

That would at least have the benefit of keeping my earlier guess on the clever side.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: Can't move files using symbolic links (allowLinking=true)

Posted by André Warnier <aw...@ice-sa.com>.

Caldarale, Charles R wrote:
>> From: peter.crowther3@googlemail.com [mailto:peter.crowther3@googlemail.com] On Behalf Of Peter Crowther
>> Subject: Re: Can't move files using symbolic links (allowLinking=true)
> 
>>> Maybe a guess : under Unix/Linux, "move" (mv) is a "rename",
>>> and it is not the same as "copy + delete original".  And a
>>> "move" (rename) works as long as the source and target are
>>> inside the same filesystem, but not if they are on different
>>> filesystems.
> 
>> Nice one André!  I'd completely missed that.
> 
> Except... I have no problem issuing a shell mv command across filesystems; the shell recognizes that this is not just a simple rename() operation, and acts accordingly.  Note that there is no move() API (for filesystems); the concept is a figment of the shell's imagination.
> 
And me thinking I'd had a brilliant insight.  There's always got to be someone to spoil it..
;-)

The perl documentation for rename() though, has this to say :
rename OLDNAME,NEWNAME

     Changes the name of a file; an existing file NEWNAME will be clobbered. Returns true 
for success, false otherwise.

     Behavior of this function varies wildly depending on your system implementation. For 
example, it will usually not work across file system boundaries, even though the system mv 
command sometimes compensates for this. Other restrictions include whether it works on 
directories, open files, or pre-existing files. Check the perlport manpage and either the 
rename(2) manpage or equivalent system documentation for details.

perl itself being written in C, is usually pretty close to the C library.  But maybe the 
above is a bit dated.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

RE: Can't move files using symbolic links (allowLinking=true)

Posted by "Caldarale, Charles R" <Ch...@unisys.com>.

> From: peter.crowther3@googlemail.com [mailto:peter.crowther3@googlemail.com] On Behalf Of Peter Crowther
> Subject: Re: Can't move files using symbolic links (allowLinking=true)

> > Maybe a guess : under Unix/Linux, "move" (mv) is a "rename",
> > and it is not the same as "copy + delete original".  And a
> > "move" (rename) works as long as the source and target are
> > inside the same filesystem, but not if they are on different
> > filesystems.

> Nice one André!  I'd completely missed that.

Except... I have no problem issuing a shell mv command across filesystems; the shell recognizes that this is not just a simple rename() operation, and acts accordingly.  Note that there is no move() API (for filesystems); the concept is a figment of the shell's imagination.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: Can't move files using symbolic links (allowLinking=true)

Posted by Peter Crowther <pe...@melandra.com>.

On 21 March 2011 20:39, André Warnier <aw...@ice-sa.com> wrote:

> Maybe a guess : under Unix/Linux, "move" (mv) is a "rename", and it is not
> the same as "copy + delete original".  And a "move" (rename) works as long
> as the source and target are inside the same filesystem, but not if they are
> on different filesystems.
> (copy + delete does work in that case).
>

Nice one André!  I'd completely missed that.

 Maybe your C application (of which you do not have the source code), tries
> to do a "move" internally ?
>
> Running strace on the process containing the C code would show that up
fairly quickly.  You'd see rename(2) calls returning EXDEV.

If that's the case, changing the symlink to be at origin or mounting a new
filesystem at origin would solve this particular problem - but might cause
more chaos if there are other moves going on!

- Peter

Re: Can't move files using symbolic links (allowLinking=true)

Posted by André Warnier <aw...@ice-sa.com>.

Goyo wrote:
> Yeah, it's a very old version. But we can't change it, anyway.
> 
> The details about the moving:
> The application (written in C), first, generates a new file which is stored
> in one directory, say "origin". This step is perfectly made.
> Then, the application moves this file to another directory
> "target". "target" was originally a regular directory, but, because of space
> restrictions, we have changed this folder for a symbolic link which points
> to another partition in an external drive. So, the path remains the same.
> 
> The machine is a Red Hat Linux release 7.1 (Seawolf).
> The server is launched with the same user who is owner of the directory.
> This directory has the following permissions: drwxr-xr-x
> And the symbolic link has all the permissions up.
> Using a terminal, we're able to copy from the first directory to the second
> directory without problems (it doesn't matter if we do through the symbolic
> link or directly).
> 
> Let's write it a little bit clearer:

Maybe you should have started this way. :-)

> We want to move a file from origin/ to origin/target/
> Previously, this movement was made perfect
> Then, we change origin/target/ for a symlink called target which points to
> another path in another partition.
> Now, it doesn't move the file when using the server application (although we
> can do it manually from the filesystem using the same user of the tomcat
> server).
> 
Maybe a guess : under Unix/Linux, "move" (mv) is a "rename", and it is not the same as 
"copy + delete original".  And a "move" (rename) works as long as the source and target 
are inside the same filesystem, but not if they are on different filesystems.
(copy + delete does work in that case).
Maybe your C application (of which you do not have the source code), tries to do a "move" 
internally ?


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: Can't move files using symbolic links (allowLinking=true)

Posted by Goyo <go...@gmail.com>.

Yeah, it's a very old version. But we can't change it, anyway.

The details about the moving:
The application (written in C), first, generates a new file which is stored
in one directory, say "origin". This step is perfectly made.
Then, the application moves this file to another directory
"target". "target" was originally a regular directory, but, because of space
restrictions, we have changed this folder for a symbolic link which points
to another partition in an external drive. So, the path remains the same.

The machine is a Red Hat Linux release 7.1 (Seawolf).
The server is launched with the same user who is owner of the directory.
This directory has the following permissions: drwxr-xr-x
And the symbolic link has all the permissions up.
Using a terminal, we're able to copy from the first directory to the second
directory without problems (it doesn't matter if we do through the symbolic
link or directly).

Let's write it a little bit clearer:
We want to move a file from origin/ to origin/target/
Previously, this movement was made perfect
Then, we change origin/target/ for a symlink called target which points to
another path in another partition.
Now, it doesn't move the file when using the server application (although we
can do it manually from the filesystem using the same user of the tomcat
server).

Any help?
2011/3/21 André Warnier <aw...@ice-sa.com>

> Goyo wrote:
>
>>  Hi.
>> I need to use a symbolic link to access a certain path in my server, where
>> I'm using Jakarta Tomcat 4.1.18.
>>
>
> Oh, a real old-timer, he ? You know how old this is, right ? I think some
> people on this list may still have been in primary school when it was
> released.
> See http://tomcat.apache.org/whichversion.html
> (and 4.1.18 is from 2003, as far as I can tell)
>
>
> We stablished a symbolic link to another path. At first, tomcat didn't see
>> this path through the symlink, but we searched for it and found the
>> allowLinking=true feature.
>> Now, it sees the path. However, and here comes the problem, it doesn't
>> allow
>> to move files to this path.
>> We've tried to move files manually with the same user of tomcat and it
>> works
>> well, but it doesn't via the web application. Besides, this feature worked
>> perfect before making this folder reachable through a symlink.
>>
>>
> Can you explain more precisely what you mean by "moving files" ? (who is
> doing the moving, from where to where, using what,..)
> (and maybe also tell us which platform this Tomcat is running on, etc..)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

Re: Can't move files using symbolic links (allowLinking=true)

Posted by André Warnier <aw...@ice-sa.com>.

Goyo wrote:
>  Hi.
> I need to use a symbolic link to access a certain path in my server, where
> I'm using Jakarta Tomcat 4.1.18.

Oh, a real old-timer, he ? You know how old this is, right ? I think some people on this 
list may still have been in primary school when it was released.
See http://tomcat.apache.org/whichversion.html
(and 4.1.18 is from 2003, as far as I can tell)

> We stablished a symbolic link to another path. At first, tomcat didn't see
> this path through the symlink, but we searched for it and found the
> allowLinking=true feature.
> Now, it sees the path. However, and here comes the problem, it doesn't allow
> to move files to this path.
> We've tried to move files manually with the same user of tomcat and it works
> well, but it doesn't via the web application. Besides, this feature worked
> perfect before making this folder reachable through a symlink.
> 

Can you explain more precisely what you mean by "moving files" ? (who is doing the moving, 
from where to where, using what,..)
(and maybe also tell us which platform this Tomcat is running on, etc..)

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org