Relative Link remembers absolute path??
 

I have a linked file that has about 6 source files that it is dependent on.
The links have been setup relatively. The user's open the source files and
the link files using a mapped drive letter that points to a remote server
\\servername\share i.e O:\ maps to \\servername\share

ie the Linked file is at o:\foldername1\linkedfile.xlsx

Some source files are located at o:\foldername1\foldername2\sourcefile1.xlsx
Other source files are located at o:\foldername3\sourcefile2.xlsx

Every so often, when one of the user's opens the file from the O drive, the
paths will look as follows:
c:\documents and settings\someusername\somepath\foldername2\sourcef ile1.xlsx

and some as just
c:\foldername3\sourcefile2.xlsx

All users SWEAR they have not saved the file on their C drive, that they
always open up on the O drive, make changes and save on the O drive. And I
believe them because I have watched them in action

Some of the mitigating circumstances that I think may play a role, but I am
not sure how is as follows

The NAS share is the following type of hardwa

a Sun NAS which does not use samba (which runs in
user space), rather it uses a smb/cifs protocol stack in the kernel.
it's a CIFS/SMB filesystem on a Sun StorageTek 5320C NAS running NAS
OS version 4.21

We implemented folder redirection and offline files using group policy and
the path to what is assigned as offline shares is the same root, but
different folders.. i.e
\\servername\differentfolder

I changed the mapped drives from using the \\servename reference to using a
cname reference
i.e \\cnameservername\share......

I made this change because we noticed that before, when the user's were
either offline, or in a connected state, but the system would not reconnect
to the server, that their mapped drive locations would not show the full
contents of the share. So I decided to use the cname to totally prevent the
offline mechanism fromaffecting the mapped drives, so that when the user was
truly offline, it would not appear as if they had access to the mapped drives.


So all of that to say, that the problem I am trying to figure out, is, why
would the Linked spreadsheet hard-code and remember these relative paths as
something off of the C drive of someone's computer

I hope that all made sense

Relative Link remembers absolute path??
 

Hi,

I would check the user's hard drives to see if there is a copy of the file
on their drive. I hate to suggest that the users are wrong, but ...

--
If this helps, please click the Yes button

Cheers,
Shane Devenshire


"booker@mgt" wrote:

I have a linked file that has about 6 source files that it is dependent on.
The links have been setup relatively. The user's open the source files and
the link files using a mapped drive letter that points to a remote server
\\servername\share i.e O:\ maps to \\servername\share

ie the Linked file is at o:\foldername1\linkedfile.xlsx

Some source files are located at o:\foldername1\foldername2\sourcefile1.xlsx
Other source files are located at o:\foldername3\sourcefile2.xlsx

Every so often, when one of the user's opens the file from the O drive, the
paths will look as follows:
c:\documents and settings\someusername\somepath\foldername2\sourcef ile1.xlsx

and some as just
c:\foldername3\sourcefile2.xlsx

All users SWEAR they have not saved the file on their C drive, that they
always open up on the O drive, make changes and save on the O drive. And I
believe them because I have watched them in action

Some of the mitigating circumstances that I think may play a role, but I am
not sure how is as follows

The NAS share is the following type of hardwa

a Sun NAS which does not use samba (which runs in
user space), rather it uses a smb/cifs protocol stack in the kernel.
it's a CIFS/SMB filesystem on a Sun StorageTek 5320C NAS running NAS
OS version 4.21

We implemented folder redirection and offline files using group policy and
the path to what is assigned as offline shares is the same root, but
different folders.. i.e
\\servername\differentfolder

I changed the mapped drives from using the \\servename reference to using a
cname reference
i.e \\cnameservername\share......

I made this change because we noticed that before, when the user's were
either offline, or in a connected state, but the system would not reconnect
to the server, that their mapped drive locations would not show the full
contents of the share. So I decided to use the cname to totally prevent the
offline mechanism fromaffecting the mapped drives, so that when the user was
truly offline, it would not appear as if they had access to the mapped drives.


So all of that to say, that the problem I am trying to figure out, is, why
would the Linked spreadsheet hard-code and remember these relative paths as
something off of the C drive of someone's computer

I hope that all made sense

we have the same problem
 

Sometimes this can be traced to when Excel crashes, then the recovered file is often remapped to C rather than the original mapped server folder. However, we have just had an incident where there was no crash. we have not implemented UNC paths instead of mapped drives until we fully understand the problem because it will require more from the users. Did UNC paths completely resolve your problem?
Does ANYONE have an explanation of why this occurs and if someone (MS) is going to fix it? Or if there are other practices than renaming the maps with UNC that would prevent the problem?



ShaneDevenshir wrote:

Hi,I would check the user's hard drives to see if there is a copy of the file
24-Feb-09

Hi,

I would check the user's hard drives to see if there is a copy of the file
on their drive. I hate to suggest that the users are wrong, but ...

--
If this helps, please click the Yes button

Cheers,
Shane Devenshire


"booker@mgt" wrote:

Previous Posts In This Thread:

On Tuesday, February 24, 2009 5:15 PM
dummy.addres wrote:

Relative Link remembers absolute path??
I have a linked file that has about 6 source files that it is dependent on.
The links have been setup relatively. The user's open the source files and
the link files using a mapped drive letter that points to a remote server
\\servername\share i.e O:\ maps to \\servername\share

ie the Linked file is at o:\foldername1\linkedfile.xlsx

Some source files are located at o:\foldername1\foldername2\sourcefile1.xlsx
Other source files are located at o:\foldername3\sourcefile2.xlsx

Every so often, when one of the user's opens the file from the O drive, the
paths will look as follows:
c:\documents and settings\someusername\somepath\foldername2\sourcef ile1.xlsx

and some as just
c:\foldername3\sourcefile2.xlsx

All users SWEAR they have not saved the file on their C drive, that they
always open up on the O drive, make changes and save on the O drive. And I
believe them because I have watched them in action

Some of the mitigating circumstances that I think may play a role, but I am
not sure how is as follows

The NAS share is the following type of hardwa

a Sun NAS which does not use samba (which runs in
it's a CIFS/SMB filesystem on a Sun StorageTek 5320C NAS running NAS

We implemented folder redirection and offline files using group policy and
the path to what is assigned as offline shares is the same root, but
different folders.. i.e
\\servername\differentfolder

I changed the mapped drives from using the \\servename reference to using a
cname reference
i.e \\cnameservername\share......

I made this change because we noticed that before, when the user's were
either offline, or in a connected state, but the system would not reconnect
to the server, that their mapped drive locations would not show the full
contents of the share. So I decided to use the cname to totally prevent the
offline mechanism fromaffecting the mapped drives, so that when the user was
truly offline, it would not appear as if they had access to the mapped drives.


So all of that to say, that the problem I am trying to figure out, is, why
would the Linked spreadsheet hard-code and remember these relative paths as
something off of the C drive of someone's computer

I hope that all made sense

On Tuesday, February 24, 2009 6:36 PM
ShaneDevenshir wrote:

Hi,I would check the user's hard drives to see if there is a copy of the file
Hi,

I would check the user's hard drives to see if there is a copy of the file
on their drive. I hate to suggest that the users are wrong, but ...

--
If this helps, please click the Yes button

Cheers,
Shane Devenshire


"booker@mgt" wrote:


Submitted via EggHeadCafe - Software Developer Portal of Choice
BizTalk Repeating Structures Table Looping and Table Extract
http://www.eggheadcafe.com/tutorials...g-structu.aspx