cp fails without xattr

[step-]

I'm testing your mod on Puppy Linux. All copy operations fail with this kind of message -- here I'm dragging 2016.txt from /root to /tmp:

Copying /root/2016.txt as /tmp/2016.txt cp: cannot preserve extended attributes, cp is built without xattr support Failed to copy '/root/2016.txt'

Done There was one error.

And the file isn't copied at all. I don't have cp built with xattr and I don't think it should be a requirement for ROX-Filer to function. How can I work around this issue with your mod? Thank you

[jun7]

Does this commit solve it?

[step-]

It kind of solves the problem but it also eliminates any support for extended attributes, which is an undesirable overkill. Puppy Linux does have command attr and extended attributes. But it doesn't support cp --preserve=xattr, that's all. So, I'm looking at your source code where I think it should be changed.

596 #if defined(HAVE_GETXATTR) || defined(HAVE_ATTROPEN)                                
597         const char *argv[] = {"cp", "-pRf", "--preserve=xattr", NULL, NULL, NULL};  
598                                                                                     
599         argv[3] = from;                                                             
600         argv[4] = to;                                                               
601 #else                                                                               
602         const char *argv[] = {"cp", "-pRf", NULL, NULL, NULL}; 
603 
604         argv[2] = from; 
605         argv[3] = to; 
606 #endif                                                                              

GNU cp manual page says

-p     same as --preserve=mode,ownership,timestamps

--preserve[=ATTR_LIST]
       preserve  the  specified  attributes  (default:  mode,ownership,timestamps),
       if   possible  additional attributes: context, links, xattr, all

--no-preserve=ATTR_LIST
       don't preserve the specified attributes

So maybe you should change line 597 to run this command

 cp -pRf --preserve --no-preserve=context,links,all      <- edit: not 'all', see my next comment

If I interpret the man page correctly the above command means to preserve:

• -p: mode, ownership, timestamps
• --preserve: mode, ownership, timestamps, and, if supported, context, links, xattr, all
• --no-preserve: context, links, all <-edit: not 'all', see my next comment

which overall means to preserve mode, owner, ownership, timestamps and, if supported, xattr. That should be equivalent to what you have in line 597, with the difference that it doesn't assume cp is built with xattr support.

Please test cp on your system before implementing this idea. I can't test cp with xattr on my system, so I don't know if it works the way I read the man page. All I can test is that with the above combination of options my system doesn't fail when I cp a file with extended attributes (and of course the extended attributes aren't copied).

Just to give you more details, when I run autoconf on my system it outputs config.h with

#define HAVE_GETXATTR 1
/* #undef HAVE_ATTROPEN */
#define HAVE_SYS_XATTR_H 1
#define HAVE_ATTR_XATTR_H 1

so you see that my system is capable of dealing with extended attributes - but that doesn't mean that cp is built with extended attribute support.

[step-]

I see that all means something different from what I thought, so try this command for line 597:

 cp -pRf --preserve --no-preserve=context,links

links seems to refer to hard links, so the above command turns hard links into their target in the copy, which I think makes perfect sense. Soft links are copied as such. It should preserve mode,ownership,timestamps and, if available, xattr.

[jun7]

Unfotunately --preserve doesn't enable xattr. So I tryed another way. It seems work on my env. Does this work?

[step-]

Yes, cp -af --no-preserve=context,links does not complain on my system and it seems to copy files/dirs correctly. Thank you.

[jun7]

I know Puppy Linux is rox's main user left, so not working on Puppy is serious issue. Thank you.

[step-]

I agree, in the sense that it's more likely for your fork to draw attention from Puppy Linux users that from users of other Linux distros. Puppy Linux has many variants, called puplets, and even a few derivatives. Each variant patches ROX-Filer in small ways, but mostly all variants remain very faithful to the original ROX-Filer source code. I'm using a derivative called Fatdog64, which is actually built from Linux From Scratch and mixed with Puppy Linux. What distro do you run your ROX-Filer fork on?

[jun7]

I'm using Arch Linux with Openbox.

[step-]

Me again. With this rox I don't get a confirmation prompt when copy is about to overwrite a file. Is this intentional? Did you change the standard prompt policy? With my standard rox - and the same configuration file - there's always a prompt for each file that is going to be overwritten. Then I can "quiet" this and the following prompts from the dialog. This rox just doesn't show any overwrite confirmation dialog. Is this correct?

[jun7]

I've not changed this area of sources. May be gtk version thing. Anyway, this is a bug. rox treats "quiet" random. "quiet" in the option and "quiet" in the abox(copy dialog) are mixed. So I will fix it.

[jun7]

Ah, I misunderstood. the both "quiet" are same. Just a bug of the copy.

[step-]

Hi, I don't think it's working. Take a look at the attached zipped screencast video. The file comparison panel in the background shows your source code on the left hand side, and the Fatdog64 rox-filer source code on the other side, both in action_copy(). In the screencast you will notice that the action window doesn't show up at all. Shouldn't it? Besides, now I'm asked to confirm each single item copy, which is very tedious... out.mp4.zip

[jun7]

That is what I misundestood. "quiet" is for each item to copy, not for over-write confirmation. So I added force option that not ask even about over-write.

[jun7]

Without "quiet", even no files exists in a destination dir, rox asks by each files.

[step-]

So how can I set/unset the force option? In the screencast you can see that the action window isn't displayed at all. No action window => no set/unset force option. I'm stuck.

[jun7]

In the screencast out.mp4.zip, action window is displayed. Is it old data? Even force check option is displayed. So it is not old one I think though.

[step-]

I'm sorry, I must have been too tired, you're right, there's a Force check box in there. Good! It behaves differently depending on the state of option Quiet. Is it intentional? If Quiet is enabled, and I copy like in the screencast, I get a first question "do you want to merge?", I enable Force, click yes, and no more questions are asked. This is good. But if Quiet is disabled, and I copy like in the screencast, I get a first question "do you want to merge?", I enable Force, click yest, and it still asks me to confirm OVERWRITE for each single file. This isn't good. It should ask no more questions, like in the first case.

Would you please also add a default setting for the Force flag in the Options window (Action windows tab). I think it should be split into two additional check boxes, one for Copy Force and one for Move Force. -- a third one for Link Force would be nice too, but it's beyond the scope of this discussion.

One way to look at the difference between Quiet and Force in this rox is that

• Quiet is about starting an action and all the actions that follow
• Force is about completing an action and all the actions that follow

The Quiet flag is always a source of puzzlement for users. Most people - me included - assume it means what Force means now, that is, over-write without asking. Instead Quiet means something like "Are you really sure you want to copy this thing?". I think that the reason why rox asks this question is that once copying has started there is no way to stop it. If there was a way to stop it (like a simple Ctrl+C for cp in terminal) then this Quiet flag wouldn't be needed. It's confusing.

[jun7]

It behaves differently depending on the state of option Quiet. Is it intentional? Yes. The source of rox is like that. You can see it in move and delete action. I only changed one word to fix the bug because the source is writen for that. (f14512f71564fa4a9c5dfee1c5c25b25295f7f73)

It should ask no more questions, like in the first case. I Agree.

The Quiet flag is always a source of puzzlement for users. Most people - me included Me too ;P But I have a certain fondness for negativity of rox to copy. Can be careless is not bad.

[jun7]

I notice, it is not good that force flag ignores quiet flag. because when force flag of delete in the option is checked, action dialog is not shown. There is quiet button, So just click the button equals that. I also think adding shortcut might make it more confusing.

[step-]

I don't know what you mean, it doesn't behave that way for me. In Options > Action windows I uncheck Quiet for Delete and uncheck Force then I create FILE /tmp/aa, right click to delete, ROX edea6e6 prompts me to confirm deletion. then I create DIR /tmp/bb, right click to delete. Again ROX prompts me to confirm. You don't get confirmation prompts?

Also, what do you mean by "shortcut" in your previous comment?

[jun7]

Sorry. I tried to implement this

But if Quiet is disabled, and I copy like in the screencast, I get a first question "do you want to merge?", I enable Force, click yest, and it still asks me to confirm OVERWRITE for each single file. This isn't good. It should ask no more questions, like in the first case.

And I said this to "shortcut". Because it skips checking "quiet".