OS/2, eCS & ArcaOS - Technical > Applications

SeaMonkey downloads and Unix permissions

(1/6) > >>

David McKenna:
 Hi everyone,

When downloading files using SeaMonkey 2.42.9esr, the downloaded files are always marked like these are when running 'ls -l':

[D:\junk\dl]ls -l
total 55308
-rw------- 1 root root 28717328 Jan  5 22:26 Bluegriffon_1-1-1r2.zip
-rw------- 1 root root  3688568 Jan  7 15:49 CUSeeMe2_1-9c.zip
-rw------- 1 root root    27946 Jan  8 08:23 ndpsmb-3.7.3-samba411-20220108.zip

 showing they can be read and written by the owner (root) only. Not a big deal in OS/2, because it pays no attention to these permissions anyway. But things get 'interesting' when you copy these files to a SAMBA server, because it DOES pay attention to these, and so from OS/2 if you try to move, copy, rename, open, or execute one of these files on the server, it doesn't work!

 Is there a setting in SeaMonkey that can change this? Or in OS/2? Why is SeaMonkey doing this? Up to now, I just do a 'chmod 777' on the files before copying them to the server, but would really like to not have to do that. Looking for some enlightenment here...


Dariusz Piatkowski:
I'm curious if this would work as a work-around?

If your SAMBA server (and therefore the Samba server account) that you are connecting to has your ID belonging to the admin/root group, would copying the files from OS/2 allow you to create the TARGET file with the Samba ID matching permissions?

In other words: make sure the Samba connection ID you are using has the best-fitting persmissions so that when you create that file on the Samba server the file inherits your Server ID permissions, as opposed to the original permissions the file was created with on our OS/2 platform.

Makes sense I hope?

I haven't tried this, but from the very start of getting my NAS box connection up and running I was always using my 'admin' ID to connect with, and on the NAS box itself I have my personal ID set as part of the 'Admin' group.

Dave Yeo:
Hi David,
As far as I know, it is a libc thing. Every program that is built with GCC and kLIBC or LIBCN does this. Though interestingly looking at my downloads directory, I see some exceptions,

--- Code: ---Z:\Mozprofiles\Downloads>ls -l t*
-rw------- 1 root root   337456 Sep 17 13:46 tafeld08.zip
-rw-r--r-- 1 root root  9467730 Mar 31  2021 test.tar.gz
-rw-r--r-- 1 root root        0 Feb 29  2032 test.tim
-rw------- 1 root root   132668 Aug 13 21:40 testlog-3.43.exe
-rw------- 1 root root 28325320 Apr 19  2021 timidity_eawpats_r12.wpi
-rw------- 1 root root  1895960 Apr 19  2021 timidity_player_2132_os2_r3.wpi
-rw------- 1 root root     4470 Oct 12  2020 tmrtest2.zip
-rwxr-xr-x 1 root root    90333 Feb  2  2021 tolower_ld.exe
-rw------- 1 root root     3695 Feb  2  2021 tolower.c
-rw------- 1 root root      696 Feb  2  2021 tolower.mak
-rw------- 1 root root     3695 Feb  2  2021 toupper.c
-rwxr-xr-x 1 root root    90333 Feb  2  2021 toupper.exe
-rw------- 1 root root    31368 May  4  2021 tracerte.zip
-rw------- 1 root root     8941 May  7  2020 tree.zip
-rw------- 1 root root    59111 Jul 17 16:04 TestDosGetDateTimeTzSetAndRuntime_exe-20130612.zip
-rw------- 1 root root    74865 Jul 18 14:14 TestDosGetDateTimeTzSetAndRuntime-20210718.zip
-rwxrwxrwx 1 root root     6228 Feb  2  2021 TOLOWER.EXE

--- End code ---

wish I could remember why. I think the toupper.exe/tolower.exe were compiled in place.
You could try chowning the SeaMonkey executable or launching it from a sh session with your ownership and test if that helps. Another option is to use some program to strip the EAs of the files. If you find chowning or such works, please report.
Other then that, we're basically stuck with it unless libc is changed and when that was brought up years back, Knut refused as he had plans.  Unluckily Knut hasn't had time for OS/2 in a long time.
I see Dariusz has posted an idea too, no idea if a good idea :)

Dariusz Piatkowski:

--- Quote from: Dave Yeo on January 08, 2022, 06:46:20 pm ---I see Dariusz has posted an idea too, no idea if a good idea :)

--- End quote ---

LOL...man this is why I have stuck with OS/2 over so many years (well, one of the reasons anyways), you always get the "opportunity" to find another way...

So here is what I did:

1) OS/2 file

--- Code: ----rw------- 1 root root     25602 Dec  6  2017 brp5470enc.ppd

--- End code ---

2) NAS box file after being copied

--- Code: ---[V:\public\raw\software]ls -ltr
-rw-rw-rw- 1 root root    25602 Dec  6  2017  brp5470enc.ppd

--- End code ---

So at least here, given the Samba connection ID (root/admin) and therefore the Samba server permissions, the TARGET fs file inherits the ID's permissions.

David McKenna:
 Thanks for the tips guys! I used Dariusz' approach and indeed, if I log on to the SAMBA server (that is running on an OS/2 machine) share as 'root' (instead of my typical user ID), then when copied the file is saved with read and write permissions for anyone else too. The user ID I was using was also in the 'admin' group (as is 'root'), but I guess that is not enough...



[0] Message Index

[#] Next page

Go to full version