| All Forums |
Register |
Login |
Search |
Subscriptions |
My Profile |
Inbox |
| Tool Warehouse |
FAQs |
Resources |
Help |
Member List |
Address Book |
Logout |
|
|
"saved working directory" error
|
Logged in as: Guest |
| Users viewing this topic: none |
|
Login  |
|
|
 "saved working directory" error - Apr. 6, '04, 4:51:31 PM
|
|
|
jrd
Posts: 2
Joined: Mar. 12, '04,
Status: offline
|
This may be a case of pure pilot error, but so far google &
other searches haven't been my friend. I have a Windows 2000
lab server being used as a build machine, and compilations
are failing on remotely mounted filesystems. Developers ssh
into the host and use cygwin for building with gnumake. We
recently added SFU to try to solve some remote filesystem
problems, but now we see new errors.
In a directory on the local disk, this works fine:
% mkdir -p foo/bar/baz
However, we have some links set up pointing to remote filesystems
from Solaris machines, so that something like /mnt/builds
is a symbolic link to //servername/export/builds.
If I try the same "mkdir" command in the remotely mounted directory
it fails:
% cd /mnt/builds
% mkdir -p foo/bar/baz
mkdir: cannot return to saved working directory: No such file or directory
If I look at the results I have foo/bar but not foo/bar/baz. In much
the same fashion,
% rm -rf ./foo
will fail with the same message, leaving only an empty "foo" directory
but removing everything below it. However,
% rm -rf foo
(i.e., without the "./" to indicate the current directory)
seems to work fine. The builds make heavy use of relative paths, so this
is a problem.
Users are running from the cygwin bash shell when they ssh into the
host. This error message doesn't seem to coming from any cygwin code,
that I can see. Has anyone seen it before? Any pointers or input much
appreciated.
j
|
|
|
|
|
RE: "saved working directory" error - Apr. 6, '04, 5:48:01 PM
|
|
|
Rodney
Posts: 2949
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline
|
Well....
We don't use Cygwin much around these parts :-)
Just to be sure I'm understanding your configuration:
You are using SFU NFS client.
You have cygwin installed.
You are using cygwin sshd and gmake.
What is it that you are building ?
I ask because if you are building Unix code you are going to
get better interaction with Interix (part of SFU now). Sshd,
gmake, and bash are all available here. And we know
that the interaction between Interix and NFS client has been tested.
That is creating/reading symlinks and other actions happen correctly.
I don't know what info cygwin is providing to the device driver.
It may be that the path is not liked because there is a lonesome
"." in it once the path is fully qualified (/XXX/YY/./foo).
If you specify the full pathname on the line it's likely okay, right?
Try specifying the full path with a current in it (/XXX/YY/./foo). If
that errors then that's the problem. If not, something else then.
> mkdir: cannot return to saved working directory: No such file or directory
That's an error message from cygwin's mkdir as it tried to walk
the file tree doing the '-p'. It sorta looks like it got lost.
I'm wondering if you came to your current location where you issued the
command via the cygwin symlink (which is different from an Interix symlink
in implementation). In resolving it's current location when it does a getcwd()
before walking the file tree the saved value from cygwin when passed (through
cygwin later) via chdir() to the device driver it's has something that's
not liked by the device driver. The error message above is likely the chdir()
failing. if you do (in cygwin) "cd `pwd`" does at this location does it error.
If so what is the value of 'pwd' (those are literal backticks there).
Again, let us know what you are building. It might be easier to use Interix.
|
|
|
|
|
RE: "saved working directory" error - Apr. 6, '04, 6:39:55 PM
|
|
|
jrd
Posts: 2
Joined: Mar. 12, '04,
Status: offline
|
quote:
Well....
We don't use Cygwin much around these parts :-)
I know. Thanks for the gentle response. 8-) So far
in our lab setup cygwin is the norm and I first
want to see if I can solve this while keeping cygwin,
to try to avoid any resistance I'll run into trying to
change the basic configuration of things, not to mention
the actual work involved in the change & verification
of the environment.
quote:
Just to be sure I'm understanding your configuration:
You are using SFU NFS client.
You have cygwin installed.
You are using cygwin sshd and gmake.
Correct.
quote:
What is it that you are building ?
It's a combination of C and Java code with a lot of
cross compilers and other tools set up (on the remotely
mounted filesystems) so that it's possible to build on
one a variety of platforms. There are shared code
files, and then OS-specific parts which are compiled
based on the target you're building for. We've successfully
built locally on the Windows 2000 machine in the past. (I
know that's vague, but hopefully not too much.) We first
ran into this problem when one developer was trying to
build a gcc cross-compiler for use on the Windows server,
I think. Because all of the tools & many automated build
areas are by default on remote filesystems, getting builds
working on non-local filesystems would be good.
quote:
If you specify the full pathname on the line it's likely okay, right?
Try specifying the full path with a current in it (/XXX/YY/./foo). If
that errors then that's the problem. If not, something else then.
I tried this originally and it doesn't work. As you say, it seems
to be related to the knowledge of $cwd somehow, but variations like
% mkdir -p `pwd`/foo/bar/baz
% mkdir -p `pwd`/./foo/bar/baz
% rm -rf `pwd`/foo
% mkdir -p /mnt/builds/foo/bar/baz
also disappointingly exhibit the same "I'm lost" error message.
I looked already in various parts of cygwin source code to see
if I could isolate where the message was coming from but couldn't
find it, which prompted me to ask here.
quote:
if you do (in cygwin) "cd `pwd`" does at this location does it error.
If so what is the value of 'pwd' (those are literal backticks there).
% cd `pwd`
works fine. Of course you're right and using only a single
environment would simplify things a great deal, but I
am hoping that someone might've seen this before & know the cause
right away. If I can get this working still in the cygwin environment
so that the developers don't see any impact, then that of course
would be the best of all possible worlds. Otherwise we'll need
to consider switching development to SFU which is really fine, if
it ends up working, but it adds another thing to be done. 8-)
Thanks again for the gracious response.
|
|
|
|
|
RE: "saved working directory" error - Apr. 7, '04, 12:02:57 AM
|
|
|
Rodney
Posts: 2949
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline
|
mmmm, okay.
Where you tried:
> % mkdir -p /mnt/builds/foo/bar/baz
the "/mnt" part is a symlink link, right?
If you locate to the same location, but using the real pathname
(I think "//servername/export/builds/...") then do the mkdir
does it work then ? (<-- I'd meant this by full path last time, but
I see now that wasn't clear).
If it works with "//servername/export/builds/..." then that should be
your workaround.
To decide whether it's cygwin or the SFU NFS client will take some digging
into the source code of the utilities, libraries and engine of cygwin to
see what manipulation is done with pathnames at the upper level before
getting passed throught the cygwin engine and then to the device driver.
At that point you will likely have enough evidence to file a bug with someone.
|
|
|
|
 New Messages |
 No New Messages |
 Hot Topic w/ New Messages |
 Hot Topic w/o New Messages |
|
 Locked w/ New Messages |
 Locked w/o New Messages |
|
 Post New Thread
Reply to Message
Post New Poll
Submit Vote
Delete My Own Post
Delete My Own Thread
Rate Posts |
|
|
|
Printable Version
