Tiny Core Linux
Tiny Core Base => TCB Bugs => Topic started by: MikeLockmoore on May 02, 2011, 09:32:17 PM
-
If you got 'em, post 'em here! Thanks. ;)
NOTE: discussion of future issues is directed to this thread: http://forum.tinycorelinux.net/index.php?topic=9517.0 (http://forum.tinycorelinux.net/index.php?topic=9517.0). Thanks.
-
hi
I am replying here instead of the wrong thread for bug v 0.9.0
1) sorry for any misleading on my last post....no results meant no results or hits for the .fluff.conf file
I do get hits for other fluffly stuff
2) so relooking at my hard drive and searching again its easier to see by just running
ls -al as a local user....file is called /home/tc/.fluff.conf
doing a search with root powers brings no extra results but is found with
sudo find / -name *fluff.conf
3) Now running TC 3.6 in vbox here is similar commands and results
(http://ompldr.org/vOGo4ag/36.png)
4) there is a suggestion that .fluff.conf is supposed to be also in /etc/skel but I can't spot it
-
Clicking on "Help" in brings up the help menu with a line reading
BETA Version 0.8.x, January 2011
Should that be changed to 0.9.x?
Second thought: Can you add a search function to Fluff? I currently use MC for searches, but Fluff is so good in every other way . . .
-
@aus9: Since Fluff will create a .fluff.conf file with default options if one is not found, I presume the Core Team decided it was not necessary to provide a default one in /etc/skel.
@OldAdamUser2: I will need to see why that help string is still like that... I provided an updated help file, but maybe that is not in the full 3.6 release? Or maybe the older help file is being restored from your personal backup when TC boots?
Search is on this wish list for possible additions.
EDIT: Discussion on future features should be made in this thread: http://forum.tinycorelinux.net/index.php?topic=9517.0 (http://forum.tinycorelinux.net/index.php?topic=9517.0). Thanks.
-
Help file is current.
Booting v3.6 base norestore displays
BETA Version 0.95, April 2011
No .fluff.conf needed in /etc/skel as the embedded default created by fluff is all that is needed to start.
Perhaps you have a fluff.tcz v0.8.x?
-
Glad the help file lists the right version. I'm not using TC 3.6, but I downloaded the latest Fluff from Mike's code page. He probably updated one place and not the other.
-
I can see a potential problem with multiple sources and supporting external source from within this forum. Afterall this topic area is TCB Bugs. I am spending time verifying non Tiny Core base issues.
-
@RobertS: Right. I was just trying to verify it was an extension clouding the issue.
-
hi
Dear Gentlemen
as agreed I still can not find my fluff.conf but I booted up TC 3.6 in a virtual machine with nothing installed on virtual hard drives and used bootcode
tinycore norestore
2) After right hand clicking a file and adding an action in fluff....I can still not see any .fluff.conf file being created.
as per image
(http://ompldr.org/vOGpxeA/fluff.png)
Please note that I ran
ls -al before and after tweaking my fluff manager
I repositioned the terminal for cosmetic reasons only
3) So consider this ....not a bug but maybe a feature request with the following supporting waffle
a) I have a hard drive copy of .fluff.conf so am not concerned personally by not finding it in 3.6
b) But if others confirm that no conf file is created if they make changes,
maybe
it will impact on those using home persistence?
Thanks for reading
-
I have .fluff.conf
-
@aus9:
Fluff works like this:
1) If ~/.fluff.conf file exists, Fluff opens it, reads the settings, then uses them to display the main window (window sizes, a set of file types and associations, some toolbar-related things, etc.)
2) If ~/.fluff.conf does not exist, these settings are set to default values, then Fluff uses those default values to present the main window (which includes an initial size that will fit in a 800x600 pixel display, a minimal set of file associations, etc.)
3) The user uses Fluff. Fluff tracks your changes in window size, how width of the directory tree window, file associations, whether to show "hidden" dot files, etc.
4) When the user closes Fluff, the file ~/.fluff.conf is created, or re-created with the current settings.
5) Your .fluff.conf file would normally be persistent if you do the normal backup of /home/tc or have a persistent home in your boot settings. So the next time Fluff starts, it will use the settings from the previous session. However, if home is not persistent, your Fluff settings would (of course) be lost and Fluff would re-create it again and again.
Therefore, if you go to look for the .fluff.conf file before you CLOSE Fluff the first time, you won't find it. I don't consider this a bug... it is just a side effect of a design decision.
If you want to see the default values, open fluff on a pristine base system then close it immediately. The settings in the .fluff.conf file will be the default settings. If you are trying to do something special regarding the .fluff.conf file or its settings, maybe PM and I will try to recommend a way to do what you want.
-
Therefore, if you go to look for the .fluff.conf file before you CLOSE Fluff the first time, you won't find it. I don't consider this a bug... it is just a side effect of a design decision.
That's a behavior observed with a plethora of apps. ;)
-
When you paste something, it does not show up.
You need to either close fluff and reopen it to see it, or go to another directory and come back.
-
Try renaming a directory and see what happens.
I have been using it for 2 minutes, and have found 2 bugs, and one feature missing.
That is why, in the past, I have just given up using it.
These things should be obvious, if you just use it a little.
-
I tried to create a directory on a usb drive (using sudo). Got the message:
Cannot create directory. System returned (13): Permission denied.
-
Mike
I don't want to be discouraging, but
Do you use fluff yourself?
I have found 3 bugs in 3 minutes.
If you use it yourself, these should be obvious to you.
-
@ Guy: No need for snark. Of course I use Fluff, and for more than 3 minutes. Maybe your usage pattern differs enough from mine that you hit more issues/bugs than I do. I try to have updates happen during TC release candidate periods so others will test it in ways that I don't. Maybe the last few changes in Fluff happended too quickly so we did not catch new issues in time for the full release of TC 3.6.
One recent change came with the caveat that certain file updates may not get displayed without forcing a refresh with the F5 key or going away and coming back. I understand this could be annoying, but it was documented. This change was the result of attempting to fix another very annoying issue. A better fix that avoids both annoying behaviors is possible, but I have not had personal time to implement it yet. Ths will be fixed when I have time.
I will try to recreate the other issues you posted and try to address them.
@everybody: If you have seen the same issues and can add detail, please post here so I can more completely understand the issues and more completely fix them.
Thank you.
-
I'm not sure I understand why Guy sees characteristics of the program to be problems. Yes, when you paste a file, you have to refresh the screen manually to see the change. It takes two seconds to learn this and less time than that to do it. Yes, ticking the sudo box does not allow complete superuser privileges. To get full privileges, you do what you must do in all other file managers--start the program with "sudo Fluff." I find the little box handy at times. Not a flaw, but a plus.
-
This topic was started to get feedback from people.
The more honest feedback that people give, the better.
I am contributing, and giving my opinion from what I have experienced.
I am not suggesting that my opinion is the only opinion.
An ideal situation would be where many more people gave honest feedback.
There are genuine bugs in fluff.
For Tiny Core to be a professional operating system, they need to be addressed.
I appreciate the contribution that Mike and others are making.
-
There are genuine bugs in fluff.
For Tiny Core to be a professional operating system, they need to be addressed.
Agreed and agreed. You posted some things I will investigate and hopefully be able to fix. But if you are just "contributing, and giving my opinion from what I have experienced" you could focus on the facts of those experiences. Is posting "Do you use fluff yourself?" professional?
If the underlying message is to be more conservative with releases (holding onto updates longer to better validate them), the point is noted.
-
Mike
thanks for the heads up on closing fluff before looking for my conf
regards
-
Mike
The majority of people do not report bugs. If more people contributed, they would be picked up earlier.
As I have mentioned before, I gave up using fluff, as a result of experiencing a number of things which did not work properly.
I asked: Do you use fluff yourself? as a result of finding 3 bugs in 3 minutes. I would have thought at least some of these would have been picked up already.
We are all on the same team, and want the best for Tiny Core. I appreciate what you are doing.
-
Try renaming a directory and see what happens.
Just tried with the current version. I could rename directories from both the left-side directory tree and the right-side details list, using both the F2 key and the right-click menu to invoke the name-editing mode. At least in my mostly-default color scheme, the background behind the name being edited turns yellow. The name changed when I pressed enter, just as I programmed. What did not work for you? Anything special about the directories you tried to rename?
Permissions? OK, let's see... I used the terminal to change the ownership of a directory to root. Back in Fluff, my first try to rename the directory owned by root failed, but Flew presented the failure in a message box. After I checked "use sudo" I tried to rename it again and it worked.
I don't see a problem yet for this one. Can anyone provide a more specific situation where renaming a directory fails?
When you paste something, it does not show up.
I just tried again. If you select a file or directory in one location, activate copy (menu, toolbar, or Ctrl+C), click on the destination directory in the left-side tree, then activate paste (right-click menu, toolbar, or Ctrl+V) in the destination, the new item(s) appear just fine. The item(s) will not automatically appear after paste *IF* you have first selected something else in the current directory. This is the caveat I mentioned earlier that I hope to remove with a better implementation in the next release. But I want to be clear... the normal Copy in one place - Switch to another place - Paste there... works just fine for me. The pasted items appear automatically with no manual intervention.
Again, I don't see a problem here as long as nothing is already selected in the destination directory. Can anyone describe other conditions where the pasted items don't appear?
I tried to create a directory on a usb drive (using sudo). Got the message:
Cannot create directory. System returned (13): Permission denied.
Just tried with my "vfat" format USB stick. I selected /mnt/sda1 in the left-side directory tree (the USB stick was already mounted using the TC Mount Tool). I right-clicked to pop up the menu and selected "Create directory". I entered a name. It was created successfully. I could create a file there too. Is there anything special about your USB stick? Ext3 format? Anything else?
I just spent several minutes trying to replicate the posted issues, but have only found normal, expected behavior. Guy, if you found the time to reply here multiple times, please take a few more minutes to better document the conditions and steps you used when you encountered the problems. And if anyone else has seen the problems Guy has posted, please post your relevant information here. I won't be about to troubleshoot the problems if I can't reliably reproduce them. I don't think I'm doing anything special to avoid these problems, so if there is something different about the environment or the specific sequence of steps that exposes problems, I need to know what they are. Thanks.
-
Try renaming a directory and see what happens.
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.
Does that work for you?
-
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.
Try this:
Insert the usb drive.
Use the mount tool to mount it.
Tick "use sudo" in fluff
Go to /mnt/partition in the left side of fluff
Click on the partition or a directory with the right mouse button
Click "Create directory"
Type in a name for the directory
Click "OK"
Do you get "Permission denied?"
I have noticed, it works if I start fluff using "sudo fluff"
This indicates a difference between using sudo fluff and ticking use sudo.
Another good reason to not have use sudo by default.
-
Doing this I noticed another bug.
After trying to create a directory, as discussed above. I can't unmount the usb drive using the mount tool, until after I close fluff.
If I do the same thing with sudo xfe, it successfully creates the directory, and I can unmount the drive while xfe is still open.
With a bit more experimenting, I have noticed, I can't unmount the partition if I have clicked on something in the partition.
If I click on something in another partition, I can unmount the drive.
-
Hi Guy
You can't unmount something while it's in use.
Open a terminal and mount something, now cd into the mount point. Try unmounting it and see what
happens. Open another terminal and try unmounting it from there, that will fail too.
-
It is not in use.
It is just while seeing what files and directories are there.
If the same thing is done with xfe or other file managers, it can be unmounted.
-
Hi Guy
When a file manager is displaying the contents of a directory I would expect it to cd into it first, and
that means it is in use. It's possible those other file managers are listing the contents without cd'ing
into the directory but that sounds like an odd and awkward way of doing it. I used midnight commander
to list the contents of a mounted directory, I could not unmount it until I told it to list a directory outside
of the mount point. That sounds like normal behavior to me and what I would expect.
Did you try what I suggested in post #26?
-
When a file manager is displaying the contents of a directory I would expect it to cd into it first, and
that means it is in use.
Yes, this is how Fluff works. It is a design decision with the side-effect that you cannot unmount without closing the app or navigating to another storage volume. I can understand that it could be annoying. Let me investigate how difficult it would be to not use chdir (change directory) in Fluff.
-
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.
-
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.
-
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.
-
@ 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 (http://forum.tinycorelinux.net/index.php?topic=9517.0). That way I can better gauge the concensus preference. Thanks.
-
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.
-
Post 400. 8)
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.
-
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.
-
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.
-
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.
-
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?
-
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?
-
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.
-
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.
-
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.
-
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. ;)
-
Mike
I thankyou for your past work and without wanting to sound like a complete troll ;) I liked the fact that TC had a file manager and for me it worked.
regards
-
I thankyou for your past work
+1
And for any future work you may do.
I'll try to be more conscientious about documenting and reporting any bugs I come across - there's an issue sometimes where fluff closes unexpectedly which I haven't taken the time/effort to nail down to where I can reliably reproduce it, but I'll do that and report. Seems the least I can do if I'm going to adopt your effort as my file manager of choice...
I had already invested some time in setting up emalfm2 to my liking before fluff came along. Extension size usually isn't a limiting factor for me, but I do like to keep an eye out for smaller and faster if sufficient functionality is there. I am following fluff, even reinstated it onto my wbar, and look forward to seeing it develop. With fluff included in base, it was a no-brainer to start the process of switching myself over from emelfm2 to fluff. With fluff as an extension, I have actually think about it and consciously make the decision to switch.
I was a bit surprised when fluff was initially included in base, not so much because of its size but because including it did seem to violate the fundamentals of Tiny Core. Useful as it is, it would have to be -awfully- tiny to justify being include in base instead of being an extension. I liked having it there in base because it gave a new user some capability to browse the base system without installing -any- extensions.
In a similar vein, I was surprised -and ecstatic- when "editor" was included, even though it too might be thought of as extension fodder. Leaving users of a base system saddled with busybox's vi (or any vi) seems cruel and unusual punishment even though the general run of Linux distros makes it not unusual at all.
-
aus9, Lee: Thanks for the kind words. I'm just about to submit the extension packages. One will be to upgrade Fluff to the latest version if you are running TC 3.6 (or 3.5 for that matter). Another will be to install Fluff on 3.7.
Lee: Hopefully Fluff 1.0.0 will behave better for you.
We'll see if my other "micro" file manager idea takes shape and gains any support. ;)
-
We'll see if my other "micro" file manager idea takes shape and gains any support.
Is that something I should know about? Or an idea not yet out in public?
-
I was just beginning to like fluff. I was thinking the extra features would not cause bloat at all, yes they will be a few kb extra but perhaps the mount tool could be dropped instead.
I would like you to keep plugging away at it Mike, it is not mature enough yet. Don't be content with just fixing any bugs; look at improvements.
-
We'll see if my other "micro" file manager idea takes shape and gains any support.
Is that something I should know about? Or an idea not yet out in public?
I've dropped hints, but mostly it's an idea not yet out in public. I may do a rough prototype and post it to get some feedback. If so, I'll probably post first in the "Programming" subforum.
I would like you to keep plugging away at it Mike, it is not mature enough yet. Don't be content with just fixing any bugs; look at improvements.
Oh, I'm not done with Fluff. I definitely plan to do things on the future feature wish list. But I have other stuff waiting on the sideline or in the early concept phase. For example, I have a FLTK GUI for configuring and managing WiFi connections, but it's only 80% or 90% ready for the first "alpha" preview. So I don't know the priority and order things will get done.
-
Have you had a look at the wifi tools in puppy? I think there might be lots of stuff that can be adapted easily.
-
Jur: Yes, I was a Puppy user before Tiny Core, and I did use its WiFi stuff. My new app has some overlap with that, it is more similar to Gnome's Network Manager, I'd say. More later in another subforum. ;)
-
hi
I am just looking at olde fluff and new fluff_upgrade
any chance you can have a fluff.png in the new one please
I am thinking of remastering my own TC to have fluff_upgrade in the wbar
2) I could grab the old icon but am too lazy...heh heh
regards
-
aus9: fluff.tcz has fluff.png icon. Can't you use fluff.tcz in your remaster? ???
-
hi
I prefer your new improved fluff but I suppose I will renege on (2) heh heh
-
Why I'm confused is that fluff.tcz is version 1.0.0 (most up to date), and it contains the icon and .desktop file. So if you remaster, you can just include it, or copy any part or parts of it you need over the version that comes with Tiny Core base. So I don't see any problem getting the icon.
Or do not understand a problem you have? :-\
Here is the .png icon anyway.
-
For example, I have a FLTK GUI for configuring and managing WiFi connections, but it's only 80% or 90% ready for the first "alpha" preview. So I don't know the priority and order things will get done.
mike, magicparted has a nice tool http://forum.tinycorelinux.net/index.php?topic=9831.msg53702#msg53702
-
Now off topic. Use topic area: http://forum.tinycorelinux.net/index.php?topic=9517.0