nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Symbolic links, Junctions, Anything

System

TeamSite Newbie
2K3 version of Teamsite 6.7.1. I need to junction (nt linkd or systernals junction) one directory in a workarea to another directory in the same workarea. Since the IWFS does not allow NTFS junctions, how can I accomplish this?

Find more posts tagged with

Comments

Adam Stoller

TeamSite Newbie
2K3 version of Teamsite 6.7.1. I need to junction (nt linkd or systernals junction) one directory in a workarea to another directory in the same workarea. Since the IWFS does not allow NTFS junctions, how can I accomplish this?

First question: Why do you "need" to do this?

Basically - symbolic links (unix or other bastardization) do not make sense to version - which is what TeamSite is (among other things) for.

If you can provide more rationale for why you believe you need to do this, perhaps we can offer better alternatives.

Migrateduser

Because our asp.net code looks at the filesystem for several of its aspx and ascx templates. We have hundreds of partners who share the same directory for their headers and footers, which have to exist on the filesystem. We currently use NTFS junctions to "fake out" the code and we need this to work in IWFS. Giving each partner its own true directory is not the answer as we need all partner directories to update immediately (<1 sec) when the primary directory is updated.
Don't blame me, i'm the admin, not the developer and the code won't change any time soon.

nipper

you *may* be able to use the proxy for this. If these call behave like an SSI or normal web traffic (that goes through the web server) then it will work.

However if these are like old C code #include statements, that goes directly to the filesystem and I doubt there is a way to do that.

ccprofessional

I have seen that iwproxy won't help with .NET code-behind virtualizations- in my experience.

Migrateduser

It is old c style includes. Their HAS to be in the subdirectory in the filesystem in order for the code to work. The problem is we don't want template producers changing that directory, just the main one the rest or the directories would be linked into.
Currently, if they change one directory, it changes all of them w/ the junction. that is what we want. W/o the junctions, if a content in a dir is changed, that change will only affect that dir and never go through as we only submit the main directory, not the linked ones (and for good reason).

ISCBorisB

It is old c style includes. Their HAS to be in the subdirectory in the filesystem in order for the code to work. The problem is we don't want template producers changing that directory, just the main one the rest or the directories would be linked into.
Currently, if they change one directory, it changes all of them w/ the junction. that is what we want. W/o the junctions, if a content in a dir is changed, that change will only affect that dir and never go through as we only submit the main directory, not the linked ones (and for good reason).

Here and there you've hinted on few interesting details ("only submit the main directory..." is one of them). So, it did work, you used to use NTFS
Junction somewhere outside of TS backing store.

What changed? Why would you need this thing in the Workarea? It looks like you and not your partners control modifications of shared assets.
If that's the case, keep it in the *regular* WA structure and create OD Configuration and Script/Workflow to Deploy to the Junction Path

Migrateduser

We're just implementing TS now, so this is the first time we've seen the IWFS. No, there was not a POC done (again, i'm just the admin).

ISCBorisB

We're just implementing TS now, so this is the first time we've seen the IWFS. No, there was not a POC done (again, i'm just the admin).

Please note that IWOV TS is not an Application Server. Normally, CMS assets are generated, previewed, approved and then Deployed
to *active* rendition environments like Web Farms, Application Servers and the like. To reiterate, TS does not normally process HTTP
requests from *live* sites (I've seen anomalies but that's another story)

So, what's wrong with the idea to keep your shared components right where they are for "active" rendition environments and modify/deploy
there from regular TS Places (WAs, STAGING/Editions)? Depending on how much of CMS functionality you want to expose to your Clients
you may have issues with Preview/Virtualization. There are may be various ways to fix that and besides, that should not be Admin problem anyway.

Migrateduser

The only real problem is for the template developers and the problems it will cause once deployed. W/o the links, they (template developers) will not be able to preview their content until they deploy it to qa, which makes their jobs MUCH more difficult and makes a much higher chance of an error going to production. The underlying code HAS to look at the file system in order to render its content.
Their is some conditioning code for different partner sites that are liked together, so that if someone is working on a change to the google information & directory, the other template developer working on yahoo (the two system directories were linked to a 3rd main directory) will overwrite the newer templates once it gets deployed to qa/production. Or a template developer will start working on files in a folder (say yahoo) where the files are not up to date since they aren't linked to the main 3rd directory anymore. In this case, these file will get moved to QA and production and overwrite the newer files since in QA and production, the yahoo directory is linked to 100+ other partner directories (such as google, overture, etc).

ISCBorisB

The only real problem is for the template developers and the problems it will cause once deployed. W/o the links, they (template developers) will not be able to preview their content until they deploy it to qa, which makes their jobs MUCH more difficult and makes a much higher chance of an error going to production. The underlying code HAS to look at the file system in order to render its content.
Their is some conditioning code for different partner sites that are liked together, so that if someone is working on a change to the google information & directory, the other template developer working on yahoo (the two system directories were linked to a 3rd main directory) will overwrite the newer templates once it gets deployed to qa/production. Or a template developer will start working on files in a folder (say yahoo) where the files are not up to date since they aren't linked to the main 3rd directory anymore. In this case, these file will get moved to QA and production and overwrite the newer files since in QA and production, the yahoo directory is linked to 100+ other partner directories (such as google, overture, etc).

It seems that solution you want should cover the following (without junctions and the like)
a) Allow concurrent development of shared assets with *standard* locking (whatever your standard is, see TS Administration Guide)
b) Provide replication mechanism to create identical assets under various WA Folders for Preview/Virtualization
c) Provide Deployment mechanism to single junction path in *live* Site environments.

There are many ways to accomplish that. For example, you can allow junction assets editing only in *master Junction* folder and create
a workflow to replicate modified components into "feigned" folders that represent junction naming. This approach will waste a lot
of disk space but it's simple to do. Or you may create dedicated Virtualization (pre-QA) environment outside of TS
and use Junctions there. And on, and on...In any case, that seems to be a task for TS Architect and developers