Re: Can't move files using symbolic links (allowLinking=true)
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 chuck.caldar...@unisys.com From: André Warnier [mailto:a...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Can't move files using symbolic links (allowLinking=true)
On 22 March 2011 08:32, Goyo goyocas...@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)
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Can't move files using symbolic links (allowLinking=true)
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 a...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Can't move files using symbolic links (allowLinking=true)
On 21 March 2011 16:35, Goyo goyocas...@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)
The (another) problem is that we can't access the source code :S 2011/3/21 Peter Crowther peter.crowt...@melandra.com On 21 March 2011 16:35, Goyo goyocas...@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)
On 21 March 2011 17:36, Goyo goyocas...@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)
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Can't move files using symbolic links (allowLinking=true)
On 21 March 2011 20:39, André Warnier a...@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)
From: peter.crowth...@googlemail.com [mailto:peter.crowth...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Can't move files using symbolic links (allowLinking=true)
Caldarale, Charles R wrote: From: peter.crowth...@googlemail.com [mailto:peter.crowth...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Can't move files using symbolic links (allowLinking=true)
André Warnier wrote: Caldarale, Charles R wrote: From: peter.crowth...@googlemail.com [mailto:peter.crowth...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Can't move files using symbolic links (allowLinking=true)
From: André Warnier [mailto:a...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
