I installed sed and zip from public channel and discovered that the following JSON files are untagged
- untagged T=off -rw-r--r-- 1 BPXROOT MVSBASIS 2111 Mar 26 09:46 ./conda-meta/sed-4.2.2-10.json
- untagged T=off -rw-r--r-- 1 BPXROOT MVSBASIS 3548 Mar 26 09:35 ./conda-meta/zip-3.0-6.json
- untagged T=off -rw-r--r-- 1 BPXROOT MVSBASIS 501 Mar 26 09:46 ./pkgs/sed-4.2.2-10/info/repodata_record.json
- untagged T=off -rw-r--r-- 1 BPXROOT MVSBASIS 495 Mar 26 09:33 ./pkgs/zip-3.0-6/info/repodata_record.json
They should be tagged as ISO8859-1. Or do I miss anything?
--
Manfred
------------------------------
Manfred Lotz
IBM
------------------------------
I installed sed and zip from public channel and discovered that the following JSON files are untagged
- untagged T=off -rw-r--r-- 1 BPXROOT MVSBASIS 2111 Mar 26 09:46 ./conda-meta/sed-4.2.2-10.json
- untagged T=off -rw-r--r-- 1 BPXROOT MVSBASIS 3548 Mar 26 09:35 ./conda-meta/zip-3.0-6.json
- untagged T=off -rw-r--r-- 1 BPXROOT MVSBASIS 501 Mar 26 09:46 ./pkgs/sed-4.2.2-10/info/repodata_record.json
- untagged T=off -rw-r--r-- 1 BPXROOT MVSBASIS 495 Mar 26 09:33 ./pkgs/zip-3.0-6/info/repodata_record.json
They should be tagged as ISO8859-1. Or do I miss anything?
--
Manfred
------------------------------
Manfred Lotz
IBM
------------------------------
Hi Manfred,
The listed files are needed for conda itself, not for end user. Conda interprets untagged files as ASCII, so that's okay these files are untagged.
------------------------------
Tatiana Balaburkina
Rocket Software
------------------------------
Hi Manfred,
The listed files are needed for conda itself, not for end user. Conda interprets untagged files as ASCII, so that's okay these files are untagged.
------------------------------
Tatiana Balaburkina
Rocket Software
------------------------------
Hi Tatjana,
I agree that is should not do any harm. I just didn't like that all json files coming from intial conda installation are tagged, and only those installed later are not.
Where is the tagging of those files controlled?
It is also ugly that the ownerships of those installed files are strange.
Here an example.
#l bin/zip*
-rwxrwxr-x 2 11039 200 884736 Jan 13 2020 zip
-rwxrwxr-x 2 11039 200 499712 Jan 13 2020 zipcloak
-rwxrwxr-x 2 11039 200 438272 Jan 13 2020 zipnote
-rwxrwxr-x 2 11039 200 454656 Jan 13 2020 zipsplit
--
Manfred
------------------------------
Manfred Lotz
IBM
------------------------------
Hi Tatjana,
I agree that is should not do any harm. I just didn't like that all json files coming from intial conda installation are tagged, and only those installed later are not.
Where is the tagging of those files controlled?
It is also ugly that the ownerships of those installed files are strange.
Here an example.
#l bin/zip*
-rwxrwxr-x 2 11039 200 884736 Jan 13 2020 zip
-rwxrwxr-x 2 11039 200 499712 Jan 13 2020 zipcloak
-rwxrwxr-x 2 11039 200 438272 Jan 13 2020 zipnote
-rwxrwxr-x 2 11039 200 454656 Jan 13 2020 zipsplit
--
Manfred
------------------------------
Manfred Lotz
IBM
------------------------------
Hi Manfred,
These files are created dynamically by conda (i.e. they are not just extracted from tarballs). The way conda creates them, they do not get tagged by USS filesystem; neither does conda tag them explicitly. This behaviour can't be changed from the outside. As for files coming from the initial installation, they are tagged by the installer.
I might be asking a stupid question, but can you please tell me exactly what is wrong with the ownership of those files?
Thanks,
Vladimir
------------------------------
Vladimir Ein
Rocket Software
------------------------------
Hi Manfred,
These files are created dynamically by conda (i.e. they are not just extracted from tarballs). The way conda creates them, they do not get tagged by USS filesystem; neither does conda tag them explicitly. This behaviour can't be changed from the outside. As for files coming from the initial installation, they are tagged by the installer.
I might be asking a stupid question, but can you please tell me exactly what is wrong with the ownership of those files?
Thanks,
Vladimir
------------------------------
Vladimir Ein
Rocket Software
------------------------------
Hi Vladimir,
Your question is easy to answer. Those uid=11039, gid=200 do not exist on our system. For the base installation the ownerships were set to the user who did the installation which is fine.
--
Manfred
------------------------------
Manfred Lotz
IBM
------------------------------
Hi Vladimir,
Your question is easy to answer. Those uid=11039, gid=200 do not exist on our system. For the base installation the ownerships were set to the user who did the installation which is fine.
--
Manfred
------------------------------
Manfred Lotz
IBM
------------------------------
That's interesting. So far I couldn't recreate this in-house (even on a system where we don't have that 11039 uid) - the owner was always set to my user ID.
Regards,
Vladimir
------------------------------
Vladimir Ein
Rocket Software
------------------------------
That's interesting. So far I couldn't recreate this in-house (even on a system where we don't have that 11039 uid) - the owner was always set to my user ID.
Regards,
Vladimir
------------------------------
Vladimir Ein
Rocket Software
------------------------------
Hi Manfred,
This is a feature of unpacking archives under superuser.
------------------------------
Tatiana Balaburkina
Rocket Software
------------------------------
Hi Manfred,
This is a feature of unpacking archives under superuser.
------------------------------
Tatiana Balaburkina
Rocket Software
------------------------------
Hi Tatiana,
It is hard for me to see this as a feature. Instead, for me creating files/dirs with unknow uids/gids is something an audit would complain about.
--
Manfred
------------------------------
Manfred Lotz
IBM
------------------------------
Hi Tatiana,
It is hard for me to see this as a feature. Instead, for me creating files/dirs with unknow uids/gids is something an audit would complain about.
--
Manfred
------------------------------
Manfred Lotz
IBM
------------------------------
Manfred,
We are going to fix it in a future release.
------------------------------
Tatiana Balaburkina
Rocket Software
------------------------------
Manfred,
We are going to fix it in a future release.
------------------------------
Tatiana Balaburkina
Rocket Software
------------------------------
Hi Tatiana,
Sounds good to me. Thank you.
--
Manfred
------------------------------
Manfred Lotz
IBM
------------------------------
Hi Tatiana,
Sounds good to me. Thank you.
--
Manfred
------------------------------
Manfred Lotz
IBM
------------------------------
If the ownership is problematic you can always issue a
chown -R uid.gid /prefix/bin
------------------------------
Joern Thyssen
Rocket Software
------------------------------