Fluff 0.9.5+ bugs and issues

[MikeLockmoore]

Try renaming something in the left column. Don't add letters on to the end, use the left arrow to move left in the name, and change something.

Yes, that is the level of detail that is helpful.  Thank you, Guy.

Using this info, I quickly reproduced and now understand the issue:  there is a major display glitch caused by the arrow keys during renaming mode.  Normally, after selecting a directory in the directory tree, pressing the arrow keys allow the user to expand or collapse parts of the directory tree.  During renaming mode, that behavior should be turned off and the arrow keys should act like normal text-editing keys.  But the current version of Fluff seems to be trying to do the tree expand/collapse stuff anyway.  If you type "blindly" you can still rename something, but this is a bug and I know roughly how to fix it.  This will be a high priority for the next release.

[MikeLockmoore]

Quote
I tried to create a directory on a usb drive (using sudo). Got the message:

Cannot create directory. System returned (13): Permission denied.

I get this with Ext2.

This kind of information is fairly important if you are posting a bug report.  

I don't have a spare USB memory stick available right now that I can reformat with ext2 to test it.  I hope to try it later tonight or at least sometime this weekend.

[Rich]

Hi MikeLockmoore
It is working as designed and was designed correctly. Consider this, you change the program to list
instead of changing into the directory, now someone unmounts it. The contents are still listed and
telling the person they are still available, now you have to start keeping track of whats mounted and where, or figure out how to handle the error condition when someone tries to do something in the
unmounted directory.

You can't view something until it's mounted, you can't unmount something until you stop viewing it.
Sounds right to me.

[MikeLockmoore]

@ Rich:  I see your point, but I also see Guy's... sometimes I find it annoying myself to not be able to unmount a USB stick without closing Fluff or navigating to another storage volume.  

Short team, Fluff will likely stay as-is, because there are several points where the code assumes that the current working directory is the same as the currently selected directory.  Changing Fluff to not make this assumption would require rewrites to each place the assumption is made... could get kind of messy.  

@ Everyone: if you have a strong preference for whether Fluff changes working directory or not as you navigate, please reply in the programming thread about new Fluff features http://forum.tinycorelinux.net/index.php?topic=9517.0.  That way I can better gauge the concensus preference.  Thanks.

[MikeLockmoore]

Quote
I tried to create a directory on a usb drive (using sudo). Got the message:

Cannot create directory. System returned (13): Permission denied.

I get this with Ext2.

OK, I have reproduced this bug using the more detailed information.  To do so, I reformatted a USB stick with ext2.  Using the command-line, I created a few test files and a test directory on it.  The contents were owned by "root:root".  I browsed the USB stick in Fluff successfully, but when I used the "Create directory" command of Fluff, I received the same error as Guy.

Up through the current version (0.9.5), Fluff uses the mkdir() API function to create the directory.  I don't think this one allows the programmer to specify an alternative owner, or override the user (as is with sudo), so the "use sudo" option in Fluff has no effect for the create directory operation.  I may be able to use a subprocess like I do for a bunch of the other operatioins like copy and delete.  If so, it should be easy to enable the "use sudo" option for creating directories too.  If the memory stick contents were owned by the "staff:tc" owner, it might been able to create the subdirectory, but I'd like Fluff to be able to force it with "use sudo".  Of course, "sudo fluff" would still work too.

[MikeLockmoore]

Post 400. 

I've made good progress on the "directory renaming in the directory tree" bug and the "creation of new directories on ext2 mounted media" bug.  After I do a bit more testing this weekend, I'll make the source code available if any of you are able and willing to recompile and test it.

[Guy]

I suggest, put the improved fluff in version 3.7rc1. It is usually not long between rc releases.

Encourage people to test it and give feedback. Very few people give feedback.

Then put any new improvements in 3.7rc2, and so on.


I suggest testing it more yourself on ext2, 3 and 4 filesystems. It seems you did not pick up some of the bugs because you used fat32.

I have only used if for a short time. There may be more bugs.

[jur]

Display Bug: After copy & paste, new files are not shown (until a refresh is forced). Normal behaviour would be to show pasted stuff immediately after paste operation.

[MikeLockmoore]

new files are not shown (until a refresh is forced). Normal behaviour would be to show pasted stuff immediately after paste operation.

Jur, the latest behavior was implemented to prevent the flicker and loss-of-selection issues *you* posted earlier.    (In other words "Be careful when you ask for something".)

Well, to be honest, this recent screen refresh "fix" is not very good.  I would like to re-do the screen refresh logic to automatically synchronize with the real filesystem state but not cause a lot of flicker and not unselect the user's current selections.  I have some ideas of how to do in a much more satisfactory way. Note: if you have something selected in the current directory, then another process moves or deletes it, you will likely see a warning message ("Files you had selected are no longer in the current directory" [Continue]) after the planned changes.

[MikeLockmoore]

Guy: I provide snapshots of each significant update to the CoreTeam.  It is their decision whether a particular snapshot is included.  Since I have now have made fixes for two bugs you posted, I imagine they will consider including them in a bugfix release (TC 3.6.1?) if it happens.  But yes, in general, I would prefer to roll out major updates early in a release candidate testing cycle so there is more time for other people to test, and more time to collect and perhaps react to feedback.

Testing on a wider variety of filesystems is a good idea, and I can try to do a few more specific types myself, but there is no way I can cover everything, nor do I want to try to do it all myself.  I need and want other people with other technical environments to test and give feedback.  That's what open source is about, right?

[jur]

new files are not shown (until a refresh is forced). Normal behaviour would be to show pasted stuff immediately after paste operation.

Jur, the latest behavior was implemented to prevent the flicker and loss-of-selection issues *you* posted earlier.    (In other words "Be careful when you ask for something".)

Oh I realize that. I think your fix broke something else. In my job I am expected to get everything working, not break something else when fixing one thing. I expect you would want the same excellence for fluff. If you don't, well is it worth including in base?

[MikeLockmoore]

Jur: Maybe it's arguing semantics, but I would say the inhibited screen update behavior in version 0.9.5 is "highly-compromised", not broken  , but I agree it is not good and have been working very recently to fix it.  The brand-new code will appear in version 0.9.7 or later, and I think will work much better overall.

I hope you understand Tiny Core apps are not my "job".  This is a free-time volunteer effort. I don't have infinite time to exhaustively test and perfect every detail for all users and their environments all by myself.  If Fluff File Manager is not up to reasonable quality levels, the Core Team could switch to something else, or go back to no file manager, as before.  If you have a better alternative, you are free to lobby for it, of course.

In hindsight, it would have been better to not release the screen update changes in the 3.6 release cycle, because I was short on personal time and tried to go a little too fast and pushed out a poor compromise.  After some long periods no feedback, the recent flurry has resulted in many fixes and improvements.  A little stressful but hopefully worth it to everybody.    I will certainly be a bit more cautious with future releases.

[Guy]

We appreciate that you are doing this.

Don't be concerned about the bugs in 3.6. The previous one had so many bugs I didn't use it.

[Guy]

Try to get the latest into each rc.

As it becomes more usable, I may use it more, and give more feedback.

It would be good if more people would give feedback.

[MikeLockmoore]

All: I've been informed that Fluff File Manager will no longer be a part of the Tiny Core Base system.  The Core Team identified its size (which has been growing in part to address robustness issues) and relatively rich set of features as being inconsistent with the small size and tight focus of other graphical utilities offered in the Base system.  The Core Team also highlighted inconsistent acceptance of Fluff among the user base as a concern.  I understand their assessment and accept their decision.

Fluff File Manager will transition to be an application offered as an installable extension in the Tiny Core official repository.  I will prepare and submit the extension package and have it ready by the time Tiny Core Base is released (and probably much sooner).

This transition will have the following advantages:

1) Tiny Core Base size will be reduced

2) The Core Team will not need to divert attention to support a relatively complex utility among users with widely varying expectations

3) I can continue to develop Fluff with less pressure to constrain size (although I plan to keep it very small compared to alternatives)

4) I can develop and release on an independent schedule, so there is less temptation to hurry on a bug fix or new feature to make the Tiny Core Base release timeline.

I believe it has not been decided yet whether or not to include any file manager in future Tiny Core Base releases.  If the Core Team does, I am sure it will be much smaller and have a much more tightly-focused feature set.  I hope to provide some ideas in this direction, but I won't push too hard in this area... I can keep myself plenty busy just in making installed apps.  Look for more info in the "Programming" area and the TCE subforums.

Thanks for the feedback and suggestions many of you provided to make Fluff better.  You should see the results of your contributions in the new extension version of Fluff.