You can't change the owner in Konqueror.

I don't even get the Advanced dialog. I can change the standard permissions easily and without error messages, but not the detailed ones.

KDE was built without libacl present.

Till, since this is your code, would you care to comment?

Em Quinta, 20 de Outubro de 2005 11:42, Thiago Macieira escreveu:
[bugs.kde.org quoted mail]
Wit pleasure, i dont get why you say that konqueror doesnt change owner and 
also why you in kde-3.5.0 can change the permissions in konqueror without the 
error messages i get and ther user i talked with in #kde of freenode get.

And i compiled with libacl and liattr.

Likely a regression, I'll look at it tomorrow.

SVN commit 473134 by tilladam:

Make the extended permissions dialog work again for people without acl
support.

BUG: 114731


 M  +1 -1      kpropertiesdialog.cpp  


--- branches/KDE/3.5/kdelibs/kio/kfile/kpropertiesdialog.cpp #473133:473134
@@ -2080,9 +2080,9 @@
     if ( properties->items().first()->isDir() )
       extendedACLs->setAllowDefaults( true );
   }
+#endif
   if (dlg.exec() != KDialogBase::Accepted)
     return;
-#endif
 
   mode_t andPermissions = mode_t(~0);
   mode_t orPermissions = 0;

I continue having the same problem.
I dont think this has anything to do with libacl since i always libacl installed.

I have the same problem, using kde 3.5 final

Having the same problems here. SUSE 10 final using KDE 3.5 final. Standard everything (kernel, etc.) apart from the upgrade to KDE 3.5.
Happens on 32 and 64 bit.

Can you guys check whether your filesystem is mounted with support for ACLs or not? 

I have build with ACL support

I know, that's not what I asked. Are your partitions mounted with acl support? Check /etc/fstab, please.

Partitions mounted with ACL?
My fstab is like always, theres no ACL.

*** Bug 117249 has been marked as a duplicate of this bug. ***

Confirmed (kde-3.5.0) that problem goes away when mounting filesystem with 'acl' option.  

There's still a bug here, in that the user should not be presented with an empty error when the acl mount option is not used.

*** Bug 118376 has been marked as a duplicate of this bug. ***

*** Bug 117984 has been marked as a duplicate of this bug. ***

"There's still a bug here, in that the user should not be presented with an empty error when the acl mount option is not used."

I'm being bitten by this. I running the KDE 3.5.0 packages for Debian unstable available on alioth. It affects all filesystems, my primary filesystem is ext3, mounted with the 'noatime' option.

I get the message: "Error: /path/to/file/goes/here". If I launch konqueror from konsole there is no aditional output. The bug hits regardless of the # of files selected, how they were selected, and under the default and advanced view. Fortunately chmod is my friend, but users who aren't fond of chmod might find this behaviour highly annoying (Especially if they don't have a use for ACLs or know what they are). I'd love to see a fix for this in 3.5.1.

Random musing: Given all of the talk on the dot recently about automated QA testing, mounting and unmounting filesystems with various options and playing with their premissions might be a good candidate for automation :)

I'm still having a hard time reproducing this. For the people seeing this, are you on Linux systems,  or something else? Also, can you please try with the properties dialog tester in kio/tests whether you can reproduce it with that one as well?

For the people seeing this, are you on Linux systems,  or something else?

Linux / Debian (Unstable) / Alioth KDE Packages

Also, can you please try with the properties dialog tester in kio/tests whether you can reproduce it with that one as well?

I'd be happy to, but:
-I'm away from my computer (holidays).
-I have no idea where / what the 'properties dialogue tester' is, and more importantly where to find it [I'd like to think I could figure out how to use it :) ].

When I get back in the new year, I'll update my system (see if kde 3.5 made it into unstable), and test vs. whatever instructions are here.

Re: comment #17, 
Linux?  Yes, Redhat Enterprise/Fedora Core

Re: comment +17,

Linux? yes SuSE 9.3
the filesystem with the ACL's is a nfs mounted volume

In reply to Comment #17.
Already said previously that i use Mandriva 2006 with kde-3.5.0 from branch_3.5

Can you please explain what you mean with "please try with the properties dialog tester in kio/tests".

I dont get why with all people happens this error and it doesnt happens with you, it seams youre not using kde-3.5.0.

There is a little test program in kdelibs/kio/tests called kpropsdlgtest, which you can use to start a propertiesdialog on a file outside of konqueror. It's not compiled by default, I think, but you can compile it by going into the kio/tests directory and issuing a "make kpropsdlgtest" there. Then you can run it by giving it a file to show the properties for as an argument. And I am in fact running 3.5 branch here.

that isnt possible, after i do make kpropsdlgtest i got pages and pages of errors; see just this last part:

/usr/include/kpropertiesdialog.h:154: error: 'KPropertiesDialog::KPropertiesDialog(const KURL&, QWidget*, const char*, bool, bool)' is private
kpropsdlgtest.cpp:31: error: within this context
kpropsdlgtest.cpp:32: error: 'class KPropertiesDialog' has no member named 'exec'
/usr/include/kio/global.h: At global scope:
/usr/include/kio/global.h:106: error: storage size of 'KIO::calculateRemaining'

But i dont see what is your doubt, many users have reported this problem, so this doesnt happens just by random.
The problem is when changing a file or files permissions, and if selecting severall files, just the first permissions file are changed and of course, dont forget that always apepars an error window that shows the path of the file in question.

It seams impossible that have passed an entire kde version and this problem continues existing.

Till why cant you reproduce this?
Dont you know how to just disable ACL option in fstab, or just remount partitions without acl option?

Due to this im forced to remove ACL build support to kde, to dont have more users complaining about MDE mandriva kde rpms.

Its a pitty that kde cant just do things for distros that dont have ACL enabled by default...

> Till why cant you reproduce this? 
> Dont you know how to just disable ACL option in fstab, or just remount
> partitions without acl option? 

Of course I tried that, and it works fine here. I've also tried various file systems which don't have acl support at all, and those didn't cause problems either. If you can give me access to a system which shows this, I can debug it further.

As you know i use mandriva 2006 and all that use it have this kind of problem, 
if u dont know anyone who haves in last case u can access mine.

SVN commit 505171 by tilladam:

Make sure that if a filesystem is not mounted with acl support, but the
acl support is compiled in, the metadata for acl setting is not set,
thus preventing and error on save, and as a result of that failure to
set permissions for all but the first file (in the multiple files case).

Thanks David, for helping me out with a Mandrake system that showed
this.

BUG: 114731


 M  +25 -14    kpropertiesdialog.cpp  


--- branches/KDE/3.5/kdelibs/kio/kfile/kpropertiesdialog.cpp #505170:505171
@@ -1493,6 +1493,7 @@
   bool hasExtendedACL;
   KACL extendedACL;
   KACL defaultACL;
+  bool fileSystemSupportsACLs;
 };
 
 #define UniOwner    (S_IRUSR|S_IWUSR|S_IXUSR)
@@ -1550,6 +1551,7 @@
   d->hasExtendedACL = item->ACL().isExtended() || item->defaultACL().isValid();
   d->extendedACL = item->ACL();
   d->defaultACL = item->defaultACL();
+  d->fileSystemSupportsACLs = false;
 
   if ( properties->items().count() > 1 )
   {
@@ -1849,6 +1851,22 @@
   box->addStretch (10);
 }
 
+#ifdef USE_POSIX_ACL
+static bool fileSystemSupportsACL( const QCString& pathCString )
+{
+    bool fileSystemSupportsACLs = false;
+#ifdef Q_OS_FREEBSD
+    struct statfs buf;
+    fileSystemSupportsACLs = ( statfs( pathCString.data(), &buf ) == 0 ) && ( buf.f_flags & MNT_ACLS );
+#else
+    fileSystemSupportsACLs =
+      getxattr( pathCString.data(), "system.posix_acl_access", NULL, 0 ) >= 0 || errno == ENODATA;
+#endif
+    return fileSystemSupportsACLs;
+}
+#endif
+
+
 void KFilePermissionsPropsPlugin::slotShowAdvancedPermissions() {
 
   bool isDir = (d->pmode == PermissionsOnlyDirs) || (d->pmode == PermissionsMixed);
@@ -2053,20 +2071,13 @@
 
 #ifdef USE_POSIX_ACL
   KACLEditWidget *extendedACLs = 0;
-  bool fileSystemSupportsACLs = false;
 
   // FIXME make it work with partial entries
   if ( properties->items().count() == 1 ) {
-    QCString pathCString = QFile::encodeName( properties->item()->url().path() );
-#ifdef Q_OS_FREEBSD
-    struct statfs buf;
-    fileSystemSupportsACLs = ( statfs( pathCString.data(), &buf ) == 0 ) && ( buf.f_flags & MNT_ACLS );
-#else
-    fileSystemSupportsACLs =
-      getxattr( pathCString.data(), "system.posix_acl_access", NULL, 0 ) >= 0 || errno == ENODATA;
-#endif
+      QCString pathCString = QFile::encodeName( properties->item()->url().path() );
+      d->fileSystemSupportsACLs = fileSystemSupportsACL( pathCString );
   }
-  if ( fileSystemSupportsACLs  ) {
+  if ( d->fileSystemSupportsACLs  ) {
     std::for_each( theNotSpecials.begin(), theNotSpecials.end(), std::mem_fun( &QWidget::hide ) );
     extendedACLs = new KACLEditWidget( mainVBox );
     if ( d->extendedACL.isValid() && d->extendedACL.isExtended() )
@@ -2465,9 +2476,9 @@
   if (files.count() > 0) {
     job = KIO::chmod( files, orFilePermissions, ~andFilePermissions,
         owner, group, false );
-    if ( ACLChange )
+    if ( ACLChange && d->fileSystemSupportsACLs )
       job->addMetaData( "ACL_STRING", d->extendedACL.isValid()?d->extendedACL.asString():"ACL_DELETE" );
-    if ( defaultACLChange )
+    if ( defaultACLChange && d->fileSystemSupportsACLs )
       job->addMetaData( "DEFAULT_ACL_STRING", d->defaultACL.isValid()?d->defaultACL.asString():"ACL_DELETE" );
 
     connect( job, SIGNAL( result( KIO::Job * ) ),
@@ -2481,9 +2492,9 @@
   if (dirs.count() > 0) {
     job = KIO::chmod( dirs, orDirPermissions, ~andDirPermissions,
         owner, group, recursive );
-    if ( ACLChange )
+    if ( ACLChange && d->fileSystemSupportsACLs )
       job->addMetaData( "ACL_STRING", d->extendedACL.isValid()?d->extendedACL.asString():"ACL_DELETE" );
-    if ( defaultACLChange )
+    if ( defaultACLChange && d->fileSystemSupportsACLs )
       job->addMetaData( "DEFAULT_ACL_STRING", d->defaultACL.isValid()?d->defaultACL.asString():"ACL_DELETE" );
 
     connect( job, SIGNAL( result( KIO::Job * ) ),

For the record, I cannot reproduce the problem on a Mandriva 2006 system, on KDE 3.5 r500000 (i.e., before the latest fix). I've tried on filesystems mounted with and without acl support.

Everything just worked fine.

If you didnt had any probs its because or build kde with libacl-devel 
installed and with that would have problems unless you would mount partitions 
with acl option (adding it to fstab or through mcc), or just build kde 
without libacl-devel installed in mandriva system, then there it all would 
run ok like i was forced to do, build kde without ACL.

It's built with libacl.

This is still broken under KDE 3.5.1 on SUSE 10.0 on x86_64 with a standard 64bit SUSE kernel and their default ReiserFS.
The fstab entry is:
/dev/sda2       /       reiserfs        acl,user_xattr 1 1

I'll add it to the suse 3.5.1 packages.

For the record, this is still broken on 3.5.1 fedora core 4 packages.  I get the error dialog box, the permissions are changed on the first file but none of the others.

Thats a fedora issue since this is already fixed for quite some time.

It might be helpful to know that I saw exactly the same bug in KDevelop when I used the file permissions dialog there:

Open a project in KDevelop:C/C++. (Again, I'm using Fedora Core 4, updated)
Open the File Selector.
Right click on some file or other.
Choose Properties.
Go to Permissions tab.
Change a permission.
Click OK.
Listen to glass breaking.

Assuming it's a Fedora issue, where should we be looking?

Re: comment #34
> Thats a fedora issue since this is already fixed for quite some time. 

Since it was fixed only *after* kde-3.5.1 was released, IMO that doesn't count as "quite some time".

*** Bug 123368 has been marked as a duplicate of this bug. ***