(*** This bug was imported into bugs.kde.org ***) Package: konqueror Version: KDE2RC2 Severity: normal Directories created using the \'New->Directory\' menu are created without any access rights for group and others regardless of the users\' umask. (submitted via bugs.kde.org)
On Monday 23 October 2000 12:30 mk@daveg.com wrote: > Package: konqueror > Version: KDE2RC2 > Severity: normal >=20 > Directories created using the \'New->Directory\' menu are created without= any access rights for > group and others regardless of the users\' umask. This directory is copied from a template which is $(prefix)/share/templates/.source/emptydir (just like anything else in the New menu comes from a template). This means the permissions are the ones of that directory - change them if they don't suit you. I see now that this doesn't respect the umask but the same happens with any template in fact. Maybe the permissions should be changed after the copying= ..... I would do that if I knew how to get the umask from the system (calling umask(2) twice is a bit hacky). Aynone ? --=20 David FAURE david@mandrakesoft.com faure@kde.org http://www.mandrakesoft.com/~david/ http://www.konqueror.org/ KDE Making The Future of Computing Available Today See http://www.kde.org/kde1-and-kde2.html for how to set up KDE 2
On Monday 23 October 2000 14:36 you wrote: > >This directory is copied from a template which is > >$(prefix)/share/templates/.source/emptydir > >(just like anything else in the New menu comes from a template). > > > >This means the permissions are the ones of that directory - change them > >if they don't suit you. >=20 > Is that so ? On my test system this is=20 > drwxr-xr-x 2 root root 1024 Oct 13 16:31 emptydir >=20 > but new directories are still drwx------ Oh I see.... You're right. The original permissions for a directory don't m= atter (applying the permissions of the original to the destination is still not d= one because when copying a CDROM we would have to do that _after_ copying everything. Not easy - and most often not wanted by the user anyway= ). =20 > I had assumed the system to be similar to the kioslave of kde1 which > used > ' if ( ::mkdir( url->path() S_IXUSR | S_IWUSR | S_IRUSR ) !=3D 0L ) '=20 > in KProtocolFILE::MkDir() (kfm/kioslave/file.cpp) > (and my bug report was apparently lost at that time). I was a lot more clueless about this stuff at that time I was just starting to maintain kfm after Torben :-) =20 > Now i have dug into this (unfortunately c++ is not my mother language) > and come up with=20 > if ( ::mkdir( _path.data() S_IRWXU ) !=3D 0 ) { > in void FileProtocol::mkdir( const KURL& url int permissions ) > which is in kdelibs-2.0rc2/kio/file/file.cpp. You're right this is where it came from. I fixed it by replacing the S_IRWXU by 0777. Since the umask is applied internally in ::mkdir this is the right thing t= o do. > Maybe this should go to the kdelibs folks ? I'm a kdelibs folk too now :-) --=20 David FAURE david@mandrakesoft.com faure@kde.org http://www.mandrakesoft.com/~david/ http://www.konqueror.org/ KDE Making The Future of Computing Available Today See http://www.kde.org/kde1-and-kde2.html for how to set up KDE 2