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; } } }

default behavior of new files and directories

TroyP

I am using TS 6.7.1 SP1.

When use create new files and folders using the TS GUI the files and folders have the users default OS group. This group is not an IWOV group and when you list the group over SSH the group shows as it would for any file and is not listed as iwglobal.

This means that no other users can create files and folders inside new directories until the group permission is changed. We have a shell script to fix the group permissions in bulk. We also have entries in our submit.cfg to fix the permissions on submit.

Is this correct OOTB behavior? It doesn't seem like it is.

Find more posts tagged with

Comments

Adam Stoller

I am using TS 6.7.1 SP1.

When use create new files and folders using the TS GUI the files and folders have the users default OS group. This group is not an IWOV group and when you list the group over SSH the group shows as it would for any file and is not listed as iwglobal.

This means that no other users can create files and folders inside new directories until the group permission is changed. We have a shell script to fix the group permissions in bulk. We also have entries in our submit.cfg to fix the permissions on submit.

Is this correct OOTB behavior? It doesn't seem like it is.

The submit.cfg is intended to fix this behavior ... on submit - that's why it's there.

If you're on Unix - you can use chmod g+s on directories to force files created within that directory to have the same group-ownership as the directory -- this is best done right at the beginning by doing the chmod g+s on the top-level workarea directory before creating any files or sub-directories (so that the sticky group-ownership setting is submitted when the directory gets submitted).

I don't believe there is an equivalent to chmod g+s on Windows.

HINT: Try to remember to include your OS information along with the product information when you make posts.

TroyP

The submit.cfg is intended to fix this behavior ... on submit - that's why it's there.

If you're on Unix - you can use chmod g+s on directories to force files created within that directory to have the same group-ownership as the directory -- this is best done right at the beginning by doing the chmod g+s on the top-level workarea directory before creating any files or sub-directories (so that the sticky group-ownership setting is submitted when the directory gets submitted).

I don't believe there is an equivalent to chmod g+s on Windows.

HINT: Try to remember to include your OS information along with the product information when you make posts.

Darn I forgot about the sticky bit - thanks.

It doesn't look like the settings in the submit.cfg have effect on sub-folders of folders that are submitted. Known/Expected behavior?

Adam Stoller

Darn I forgot about the sticky bit - thanks.

It doesn't look like the settings in the submit.cfg have effect on sub-folders of folders that are submitted. Known/Expected behavior?

After a folder has been submitted once - it is no longer versioned by TeamSite - only the files within the directory(ies) are versioned. Thus if you create a directory with mode bits 755 submit a file within that directory (thus "submitting the directory") and then do a chmod g+s on the directory and submit another file from within that directory ... I'm pretty sure the information for the directory does not get updated in the backing store.

Meaning - that if you then create a new workarea and do a Get Latest in it - the directory in question will most likely show up with 755 permissions.

On the other hand - if you create the directory, do the chmod, then submit the files, and then create a new workarea and do a Get Latest - the directory should have the g+s mode bits set in it.

TroyP

After a folder has been submitted once - it is no longer versioned by TeamSite - only the files within the directory(ies) are versioned. Thus if you create a directory with mode bits 755 submit a file within that directory (thus "submitting the directory") and then do a chmod g+s on the directory and submit another file from within that directory ... I'm pretty sure the information for the directory does not get updated in the backing store.

Meaning - that if you then create a new workarea and do a Get Latest in it - the directory in question will most likely show up with 755 permissions.

On the other hand - if you create the directory, do the chmod, then submit the files, and then create a new workarea and do a Get Latest - the directory should have the g+s mode bits set in it.

I don't think we are talking about the same thing. Let me restate my last question.

1. start with two new folders "/folder1/folder2" that are owned by a non-TS group
2. submit folder1 using the TS gui but not folder2.
3. Now, the entire contents of folder1 have been submitted but the group ownership on folder2 is still the OS group and not the TS group as defined in your submit.cfg

TS 6.7.1 sp1, RHEL4

Adam Stoller

I don't think we are talking about the same thing. Let me restate my last question.

1. start with two new folders "/folder1/folder2" that are owned by a non-TS group
2. submit folder1 using the TS gui but not folder2.
3. Now, the entire contents of folder1 have been submitted but the group ownership on folder2 is still the OS group and not the TS group as defined in your submit.cfg

TS 6.7.1 sp1, RHEL4

Are there any files within folder2 (which is a sub-folder of folder1 - right?) If not, it probably won't get submitted, and therefore the submit.cfg won't come into play.

Or - put another way - if you look in STAGING - do you see folder2?

The chmod g+s trick is a great way to make sure that group-ownership of all files and directories is create when they are created, and not waiting until they get submitted (again, on Unix only)

TommyWillB

This isn't really working for us on TS 6.7.2SP2 on Solaris.

My default unix group is "customer" and my TeamSite group is "Help".

1) We set a directory under our workarea to have this:

TeamSite Permissions:

owner = me
group = Help
Read & Write by owner/group/others

2) We then set validate that this directory was owned by iwglobal from the unix perspective.

3) We then set the sticky bit on the directory.

4) I created new files/folders and they came out iwglobal from unix

5) ...but from TeamSite things were funky:

Group = Help, which is correct
Permissions are now Write only for me (owner)
Read & Write by group/others

6) I tried to generate a Forms DCR>TPL HTML file into the new "iwglobal" directory and it failed (An error occurred during PT compiling. Please see more details in log files.) What log?

7) But if I:

go into that new directory
do File>New File "index.html"
it then lets me successfully generate (overwrite) the new index.html

So, I can't figure out how to make it so our content owners can create new files without going thru the odd step of creating a blank index.html file before doing that generate.

And why does making a directory sticky make TeamSite suddenly think it's owner Write-Only?

Adam Stoller

What is your umask?
If it's 002 - rather than 022 - that would explain it.
The chmod g+s only makes sure that the files and directories that are created within inherit the group ownership information, not the group permissions.