Tiny Core Linux
Tiny Core Base => TCB Bugs => Topic started by: jur on April 19, 2011, 10:17:18 AM
-
All tcl3.6rc3:
1. fluff closes when using an empty clipboard to paste
2. fluff fails to copy & paste hidden files such as .conkyrc. from one mounted drive to another. (Booted from usb stick, wanted to get my .conkyrc from /mnt/sda5.)
3. The edit button disappears when the relevant file is a shell script. How am I going to edit the file?
4. The Paste button greys out when changing drives after pressing to copy button, but paste still works (IF the file isn't a hidden one).
EDIT: Edited title to more accurately reflect the issue, as there was no change to fluff in 3.6rc3
-
Jur: Thanks for the reports. I will try to reproduce and fix as many as I can for TC 3.6. I don't have TC 3.6rc3 installed yet, but I guess that these issues will still appear under TC 3.5.1, so I will start there.
Some clarifications, if you could help me understand more fully:
1. How do you use Paste if the clipboard is empty? EDIT: I noticed a crash if I use Ctrl+V keystroke combo. It should be fixable. ::)
3. Did you loose a file association for the shell script file type? Right-click the status bar and select "Filetypes". Do you still see shell script in the list? If you open the "Associations" do you still have an edit command defined? If not, can you add one?
4. What does "changing drives" mean more precisely?
-
1: Right-click on right panel and select Paste - -> crash.
3: I think it might be handy if the edit command stayed by default for most/all file types, and file actions could be added. At last for shell scripts, the edit button could remain.
4: Click on say sda2 in left panel, select a file for copying, press copy, Paste button become active, now click say sdb1 in left panel, Copy button is greyed out.
[edit]All of the above behaviour I saw while booted from the usb stick. Last night I checked when booted from the HD but could not reproduce the behaviour. I will have to check again later using the usb stick.
-
I don't want to be discouraging or critical. I think fluff is an improvement to Tiny Core. Keep up the good work.
However, when I have used fluff, I have experienced things not working properly. So I gave up using it, and use xfe.
I saw on another page, there is a newer version of fluff available. Consider updating to that.
I then think there should be much more testing of fluff.
I don't remember much of the details, as I gave up using it. Just going from memory.
Copy and paste is one example. Sometimes it does not work properly.
Sometimes fluff closes unexpectedly.
I think "use sudo" does not work. I think it is best to remove it. People who want to use sudo, can start it using "sudo fluff."
I suggest, update to the latest version, and fix the bugs you know about.
Then encourage people to test it.
-
Hello Guy. I am trying to fix the bugs I know about. Like all software, developer(s) can more quickly and more thoroughly fix bugs if they have good, specific information from users, especially if the user is able and willing to provide concise instructions for reproducing the problem. I very much appreciate it when people like Jur take the time and effort to post their problems and information about how it happened. I have already identified a flaw in the Fluff code that leads to the segfault problem Jur reported in the first item of the list. I expect to post a new version that fixes at least this one problem within a few days. Maybe I can also reproduce and troubleshoot the other problems too. We shall see.
More general reports of problems or dislikes, such as the things you wrote, are taken as feedback, and will be considered when I work on things. But typically the level of effort I put into troubleshooting and fixing a problem is commensurate with the amount of detail that is reported. "Copy and paste is one example. Sometimes it does not work properly" is a quick comment this does not motivate me much to dig in and hunt for a bug or design flaw. Copy and Paste works fairly well for me right now, so I need more detail to understand and fix a situation in which it does not work.
By the way, the 'use sudo' option clearly does work (at least for me) in some circumstances. I don't know why it does not work for you. ???
Yes, I want people to test Fluff! And post descriptions of anything that is broken, misleading, or unexpected. Also general feedback and suggestions. But I'm mostly working on it alone, so I can't do everything suggested, of course.
The Core Team decided to include Fluff in the base. I agreed to that and tried to support that choice by quick turn-around of fixes and suggestions. But it's true that Fluff is not at mature as some file managers out there, despite the higher visibility. But it will get more mature more quickly with detailed, high-quality feedback. Right?
I hope that sounds reasonable. :)
I think I've posted many times that I think XFE is a good file manager. I used it extensively before I got Fluff to the point it was working well for me. Keep using it if it is what you like and works for you.
--
Mike Lockmoore
-
All of the above behaviour I saw while booted from the usb stick.
Jur: Yes, I hope you try again and let me know if the USB stick session behaves differently. Do you have any insight as to why? Maybe file ownership/permission issues?
-
Mike, I booted again from that usb stick but am unable to repeat the paste bugs. ??? I tried a few things but no, everything works (except for the segfault).
All I can conclude now is that what Guy said seems to be the case. :( I definitely had problems, because I tried many times, and finally resorted to using rox. But now, no problem. ??? ???
-
Jur: I appreciate the effort to retry. Maybe during the earlier problem, the USB stick was mounted in a way that prevented writing? If it comes up again, maybe try some command-line equivalent commands and see if they work even if Fluff does not. But if they don't work either, maybe something is going on with the file systems. If it is a bug in Fluff, it seems sporadic, so it will be hard to catch and fix! :-\
New Fluff version 0.9.2 prevents paste from happening at invalid times. I also (re?)added a default edit file association for shell script files. I will pass this to the core team. If it is not too late, I hope it will be released for testing in another 3.6 release candidate, 3.6-rc4, speculatively. The source code is available now at http://retrospectiva.krautsoft.de/projects/useful-lightweight-software/browse/fluff/trunk (http://retrospectiva.krautsoft.de/projects/useful-lightweight-software/browse/fluff/trunk)
-
Mike, I found another obscure bug, encountered when running fluff for the first time:
In a terminal delete (or rename) .fluff.conf. Now open fluff. Right-click on status bar, select file types. Click in the Filetype Name box (which will be empty). Type any character, fluff closes.
I was wondering if the earlier problems I saw was also to do with opening fluff for the first time... so I again deleted .fluff.conf, opened fluff, and tried to reproduce the paste bugs, no success.
-
Another bug:
I am using openbox wm and tint2 panel. When minimising fluff, it closes instead. Same happens when I switch desktops.
-
Jur: Thanks again for the problem reports. The filetype name bug should be fairly easy to fix.
For the closing under openbox, are you saying the Fluff stops running (the process disappears)? Can you tell if it segfaults? (Launch Fluff from a terminal and repeat your test.) I'm using FLWM, so I don't have much insight into alternative WM issues. Maybe Jakob B. can help me? Or anyone else who works with a *box WM?
UPDATE: The filetype name bug is fixed. To create a new filetype, I had intended the user to first click the “Add Type” button, which will pre-fill the type name field. Before the user clicks on “Add Type”, there is not a selected type, so Fluff tries to apply the changed (new) name to a type that does not exist, resulting in a segmentation fault. The fix is to disable the filetype name field and the filetype hint fields whenever the dialog box is first opened, before a hint is selected. Now the user is forced into the sequence I intended if they want to create a new type. The change will be in Fluff version 0.9.3. Available now at the same retrospectiva repository http://retrospectiva.krautsoft.de/projects/useful-lightweight-software/browse/fluff/trunk (http://retrospectiva.krautsoft.de/projects/useful-lightweight-software/browse/fluff/trunk).
-
There were no messages in terminal. It just closes - it is no longer listed under 'ps'.
I suspect is not compliant to the opendesk standard?
[edit] freedesktop.org. not opendesk
-
FWIW -- I think Fluff is coming along beautifully. It is now developed to the point where it entirely replaces emelfm for me, but I still do find times when I prefer mc. The double panels of mc make copying files from one place to another as easy as it is possible to be (though copy-and-paste with Fluff is not much harder)-- and the file-search function in mc is also important.
That said, Fluff has clearly earned its place as the default file manager in TC.
-
2 more fluff bugs:
1. When closing the editor using ctrl-Q, fluff also closes (if there were several editor instances open, this happens on the last one to close).
2. Fluff flickers annoyingly and files in rh panel lose focus when directories are dynamically changing. Good example is while loading an extension, with the focus on /tmp/any-file-in rh-panel.
-
Here is a fluff bug which you should be able to reproduce.
While running Tiny Core from a usb, or cd, I tried to delete the boot directory of the hard drive.
It cannot be deleted.
It contains a file with root:root owner and rrr permissions.
If I have xfe installed and run it as root, the boot directory can be deleted.
-
Jur: The Ctrl-Q and flicker issues will not be simple to address. The TC Base editor is not the only app that will do this. It seams that FLWM will pass up a keystroke event that should be "swallowed" completely by the child process back up to the parent. There is another minor form of this issue within Fluff's windows... so I have a "Ignore next keystroke" variable to help sort it out. However, I don't have a good method yet to distinguish between the Ctrl-Q events from a child process and from Fluff itself. Maybe someone can suggest something or I can think of a better way.
The flicker behavior now is by design, but maybe not universally acceptable. Myself, I want Fluff to automatically update its display windows when the filesystem content changes. Yes, it does cause some flicker, but I don't mind too much. I've worked a little at making the flicker less annoying by attempting to control the timing of it, but don't have a method that works well in all cases. If many other people don't like this behavior, I suppose I could provide an option where you must manually refresh anytime you want to see new content.
Guy: Did you start Fluff as the root user ("sudo fluff") or try using the "use sudo" option within Fluff? I will try to reproduce the issue with a dummy directory with the same ownership and permissions... I don't want to experiment with my PC's real boot directory. :o
-
Guy: Did you start Fluff as the root user ("sudo fluff") or try using the "use sudo" option within Fluff? I will try to reproduce the issue with a dummy directory with the same ownership and permissions... I don't want to experiment with my PC's real boot directory.
I tried both methods. It does not work either way.
-
I recommend you remove "use sudo."
This makes it more child proof, idiot proof and mistake proof.
If you ever watch children on computers, they just click everything and see what happens. If it can be messed up, it will be. I have seen children make older versions of Windows unusable in a very short time.
Some adults are not much more clever.
All of us make mistakes sometimes.
A child can easily click "use sudo," then start deleting files. Most children would not think of opening the terminal and typing sudo fluff.
This reduces the likelihood of the operating system being messed up.
-
Mike:
For the ctrl-Q bug, perhaps you can start a counter for every child editor process, decrementing the counter if any child process is ended.
For the flicker/focus issue, this is quite serious. For example, my default download location is ~HOME. This is also the default when opening fluff. So fluff becomes unusable for as long as a download is happening!
I would suggest a 3-pronged solution:
1. Do not let focus be lost when rescanning
2 Rescan for changes less frequently, say every 2s at most.
3. For a rescan, do not update the window unless something visible has changed.
-
Guy:
I should have pointed out earlier that there is a config file option "AllowUseSudo" that has been part of Fluff for many releases now. Someone during the TC 3.3 release candidate period made the same point as you (was it you?), so the option was added back then. It's documented in the help file. If you set the value to zero, the "use sudo" option completely disappears from the GUI. I think I will update the help file so the special config file options are placed into their own section.
Jur:
I will see if I can do more to reduce flicker... probably as you say and repress multiple updates within a reasonable period. And try to prevent any loss of selections during an update. But I would like to prioritize a few other things like the unexpected closing from Ctrl+Q first.
Right now, Fluff does not really track child processes. To implement full tracking to know when child processes go away would require more code than I'd prefer to add at this time. But I have another idea I hope to test later today. I'll let everyone know if it works.
-
Good news. The method I mentioned in the last reply to distinguish a spurious Ctrl+Q from a child program works! ;D I suspected there would be a GUI event related to focus that happens just before the keyboard event arrives. I have fluff record an accurate version of the system time for each FL_ENTER gui event, and if it happens too soon (0.15 seconds or less) before a Ctrl+Q keyboard event, I have Fluff ignore it. This fix is in Fluff version 0.9.4.
I also added code to inhibit automatic refreshing of the current directory's file list display if there are any selected items, or if there was already a recent (< 2sec. ago) refresh. The method I used is not ideal, because some display changes might be inhibited indefinitely, but it should get rid of most of the annoying flicker and loss of selections that Jur posted. Also in Fluff version 0.9.4. Note: you can force a refresh with the F5 function key, or by clicking on a different directory then coming back to the original one.
I have posted version 0.9.4 to retrospectiva (links earlier in this thread). I will also send it to the core team, but it looks like I missed the 3.6rc4 window today. Since they are in a "feature freeze" I don't know if this will be considered for the official 3.6 release of TC or not. Maybe there will be rc5 if there are some other fixes that need to be tested.
-
I will gladly upgrade fluff to 0.94 for 3.6 final.
-
Looking forward to 0.94. I have resolved to avoid using rox as much as possible, both to get used to fluff as well as to try and expose bugs.
I can confirm the segfault and file type bugs are fixed in 0.93.
I have a few items for a wish list. I don't know of a wish list thread?
1. Either auto-mount drives when clicked on, or have a mount button for same.
2. Have a compact list mode - I am not that often interested in exactly what permissions, file size etc the files are, but rather to see more fils at once.
I also have a question of differing behaviour of the mount tool:
If I am running flwm, using mount tool just results in the drive being mounted. But in openbox, another fluff instance opens in the newly mounted drive. Why this difference?
-
Either auto-mount drives when clicked on, or have a mount button for same.
I think the user needs a choice. Sometimes I click on a partition in the file manager to see if it is mounted. I don't want to mount it. I just want to know. For example, before removing a usb drive.
Having a mount button, or menu item is a good idea.
Hopefully I will have time to test it more when the new version comes out too.
-
Here's another bug (?) or is it due to another extension that needs to be loaded?
With large files, the file properties are not listed. I was manipulating a 1.6GB file and noted there were no permissions, properties etc listed in the right panel.
[edit] the file is 2.7GB. All properties are shown as null in the dialog box, dates are 1/1/1970. Obviously the properties are not populated.
Rox showed the properties correctly, so it would seem another extension is not needed.
-
Jur/Guy: I have not wanted to overlap the functionality of the mount tool. Maybe RobertS and I can make a way for Fluff to request a mount from the mount tool. Maybe I can also figure out a simple and light way to display an "unmounted" status in the directory tree and/or file list explicitly. No promises. I've configured a crude form of click-to-mount in Fluff through file associations before, but that is not generally useful or friendly, admittedly.
Jur: I've never tested files > 1 GB. I get the file properties via highly standardized stat() and related API calls. Was it only the really big file that had no properties populated? Were there other files in the same directory (or at least volume) that _did_ show proper properties? Reproducing this issue may be tricky for me... I don't have 2 GB spare on my main laptop's hard disk to create a test file or any USB sticks. :P Let me think about that.
I've posted a wish list thread some time back. Here are a few things I've considered:
a) User-customizable font size for buttons, view panes, etc.
b) Three-pane mode that would work more like MC
c) Thumbnail view (icons and/or thumbnail images)
d) Temporary command line for a selected file (works as a "one shot" file association)
e) Search through file names, or file content
I'm probably forgetting a good idea or two...
We can add the compact listing mode to the wish list. I don't use that mode often in other file managers. Coding it would require a different slection/highlighting method, but so will thumbnail mode, so if I implement one, the other may not be much more work.
One caution about new features: the CoreTeam is very committed to keeping the Tinycore base system very small and focused on common-denominator features that are appreciated by most users. I've added a few hundred bytes to Fluff fixing these recent bugs. That is the right thing to do, but I'm sensitive to it. Adding "nice to have" features will start to raise objections from the CoreTeam at some point. 5K more? 50K more? 500K more? I'm not sure exactly as I don't have a specific size budget. But I think it's already at a point that each update will require a fairly strong justification.
Of course, perhaps some of these wish-list things could be added to a "Super Fluff" version that is loaded as an extension, maybe replacing the base version. I took that approach with Fl-PicSee picture viewer back when it was included in the base, and I wanted to support slide show and a few other features. We shall see if I have time or support from other developers to do these wishlist items.
-
Mike, just create a sparse file. Assuming a linux fs you can just do:
dd if=/dev/zero of=testfile count=1 seek=2048000000
ls -lhn testfile
-rw-rw-r-- 1 1000 1000 977G 2011-04-26 20:41 testfile
Guess if I have 1tb free space ;)
-
curaga: Thanks. Will that work even if I don't have that much RAM or backing storage?
-
That file will take exactly 512 bytes, regardless of its size.
-
curaga: Cool! I learn something new. :D
-
Jur: I did some experiments. The limit is 2.0 GB. At that size and bigger, the lstat() and stat() API functions cannot return a valid file size:
lstat: Value too large for defined data type
So I found 64-bit versions lstat64() and stat64() that work with an expanded file information data structure. So Fluff version 0.9.5 of Fluff now properly shows file size and the other attributes when the files are a greater than 2.0 GB in size. ;D
New source code is posted at retrospectiva (see earlier in thread for link) and will be sent to the CoreTeam.
-
Mike, I'm interested in testing Fluff 0.90 (and above) without changing my OS from TC3.5. Hence, I went to your Coding Outpost page and downloaded fluff.tcz. I put it in my TCE directory and set it up as "on demand". Unfortunately, I still end up with Fluff 0.80 when I try to invoke it. I will see if moving it to "on boot" makes any difference, but I thought I would ask you how you invoke fluff.tcz in case I am doing something wrong.
Is there a way of changing the width of the directory panel (left panel) in Fluff 0.80? I notice that you have a much wider left panel in the screen shots on your page.
-
OldAdamUser2: I think you should be able to do an OnBoot installation and see a second file manager icon in wbar. The newer one will be labeld "Fluff" instead of "FileMgr". If you don't want both there, you can use the "Wbar Conf" tool from the control panel to hide one of them. It seems like OnDemand should work too, I'm not sure why it did not work for you.
To resize the amount of space allocated to the directory tree versus the file list, click and hold down the left mouse key over the margin space (maybe called a "gutter") between them, then drag it to the desired place. Release the left-mouse key and Fluff will remember this setting (assuming the $HOME/.fluff.conf file is backed up). You know you clicked the correct margin if the mouse pointer changes to a left-right arrow (<->) symbol while you drag the mouse.
-
Thanks, Mike. My left mouse button is starting to wear out, but I finally got it to work!
-
hi
not sure if its a bug or not but just trying out 3.6
I seem to recall having a /home/tc/.fluff.conf for 3.5.1
but 3.6 live cd with fluff v 0.95
sudo find / -name fluff*
sudo find / -name .fluff.conf
---> no results
I do not want to be the first to reply to Roberts news as it is only a minor issue for me but maybe someone can confirm if they use fluff?
2) In particular I then right hand click a file in fluff and choose open with
and create a new "mime" type action
Next I double click my test file to check it opens with the new executable
then I look for my fluff.conf using above commands and still no joy
-
@aus9: Hello. Thanks for posting. That seems strange... the find command at the command line cannot find the fluff executable, but you can run it from the icon in wbar? Maybe the capitalization? I write 'Fluff' if I'm just talking about it (like the title of a book or song), but the executable is named with lower case: 'fluff'. What happens if you try the command 'which fluff' ? I have a broken CD drive, so I can't boot it the same way as you. :-[ Can anyone else try this out and post your results?
@all: Maybe time to open a new Fluff version 0.9.5+ thread?