xffm issues

[Danny]

Hi!

Am Sam, 2003-08-16 um 05.01 schrieb edscott wilson garcia:
> Hi Danny,
> 
> On Fri, 2003-08-15 at 15:30, Danny wrote:
> > Hi, Edscott ! :)
> > 
> > Here are a few things I found out while moving data (~100 GB in small
> > files) out of one (damaged) partition to another one O_O
> > 
> > 1) the file manager has folder "a" marked and opened, however when I go
> > to a shell, delete the folder (among others, with wildcards): xffm
> > crashes
> 
> Please generate a traceback if you can reproduce the situation.

yuppy, will try...

> > 
> > 2) newly added files go even above the ".." entry... is that intentional
> > ?
> > example:
> > file1.zip
> > ..
> > file2.zip
> 
> It means the monitor option has "found" the new file. I like new files
> to go on top, but you can also use the mcs_manager to make xffm put them
> on the bottom. They will be sorted if requested by the user or if the
> directory is reloaded.

oic :)

> 
> > 
> > 3) the order which the folder is usually sorted will be distorted by
> > dropping new files into the folder (thats good), but the menu thinks
> > they are still sorted and doesnt let me really sort them f.e.by name
> > again (thats bad)
> 
> The menu is to change the sort method, and resorts only if the sort
> method has changed. What you want is to click on the "refresh" item
> which is the first menu entry. That will resort and find anything new

Hehe what shortcut does it have ? (Where can I look so I don't bug you
with these kind of questions? ;))

> that has been missed without changing the sort method. The selected sort
> method can be different for different folders on the same level, but
> subfolders inherit sort method from parent (until you change it with the
> popup menu, of course).
> 
> > 
> > 4) what is the keyboard shortcut for "rename" ? 
> 
> Rename, ctrl-R

Why is the keyboard shortcut not listed in the Popup Menu beside
File>Rename (to the right of "Rename") ? ;)

> > What about
> > re-implementing shortcut-by-pressing-key-in-popup in the future;)
> 
> I don't understand what you mean :-( 

The functions which do that are gtk_menu_set_accel_path, _group, I
believe ... Like, one can set the keyboard shortcut of a menu item by
hovering over the item and pressing the keys to be used in future for
this item.

But now that I know it's Ctrl+R, this isn't that important anymore ;)
I just kept trying to assign the popup menu item a key since there was
none listed to the right of the item... But since there is a shortcut,
alright ;)

> > 
> > 5) the file is not selected anymore after renaming, which is bad when I
> > rename a file and then intend to move it (f.e. when renaming 1000504905
> > from lost+found to dtt001.zip and intending to move it to "dtt"...)
> 
> Since it receives a new name it does not seem logical for it to remain
> selected since it is no longer the object of the selection, but yes, a
> way to move a file from one folder to another and receive a different
> name is missing. Something like: 
> 
> "mv /lost+found/xxx /dtt/dtt001.zip"
> 
> I wonder how that can be done in the dnd cut+paste environment...

Well, if the file stayed selected, it would be spotted more easily by
the user and he will drag it then ? :)  Two-step action is fine, but
since the "current file mark"(lol) is forgotten...

> > 
> > 6) when dragging a folder, the view does not scroll when I reach the
> > borders - f. e. if I want to drop it into a folder which is not
> > currently in the visible area (I bet this is gtk issue)
> 
> Yes. This is the second time it is noticed. AFAICT, it is a bit
> complicated to implement so it has been postponed to 4.2 so that it will
> not introduce bugs for 4.0. Make sure it's in the Wiki TODO so we won't
> forget.
> 
> > 
> > 7) when marking multiple files, and then using the mouse to drag the
> > selection, the selection gets reset to 1 file... I suppose this is a gtk
> > issue, but anyways... aaargh annoying;)
> 
> gtk issue, yes, but easy to overcome once you get the hang of it. You
> can begin the drag as soon as the selection is finished without raising
> the button. If you forget, you can always ctrl click on the last item
> twice and begin to drag before you release the second ctrl-click. 

Okie, will do it like that, then ^^

> > 
> > 8) when moving a directory, and the file permissions of any subdirectory
> > disallows moving/writing-to-directory-list (u-w), then the move is
> > incomplete as some files remain at the source. If I then drag the
> > remaining files to the same destination, it asks about overwriting
> > folders / deleting stuff instead of just updating the already existant
> > folders.
> 
> On purpose. If a directory with the same name is found, it does not know
> why it is there and it will ask you if you want to move it to the trash
> or delete by overwriting. It's just a safeguard against mistakes. 

Ok then :)

Though a mode "automatically overwrite if newer [or equal]" would be
cool, for updating folders... though I didn't think that through yet...

(nooo, I don't mean to clobber the replace/delete dialog, but add a
option to xffm itself for "automatically overwrite files by newer
eeeverywhere" yes/no)

> 
> > 
> > Also, what about automatically doing chmod u+w for moved folders and
> > subfolders ? (perhaps remembering which and resetting them to the
> > original state after the move)
> 
> Moved and copied folders and files should have the same mode as the
> originals. If it is not working this way, it would be a bug. Files
> should even get the same modification date as the originals to
> distinguish that the content is the same.

Yes, but thats not what I mean.
What I mean is that:

/home/dannym/blah1          directory, r--------
/home/dannym/blah1/file1    5 bytes, rw-------
/home/dannym/blah1/blah2    directory, r--------
/home/dannym/blah1/blah2/a  1000 byte, rw-------

use xffm to move "file1" and "blah2" somewhere else -> *boom* permission
denied (for removal of the said files from the source directory, and
from removal of "a" from the "blah2" directory).

To prevent that from happening, what about automatically doing:

saved_state.push(mode("/home/dannym/blah1"))
saved_state.push(mode("/home/dannym/blah1/blah2"))

chmod("/home/dannym/blah1", "u+rw")
chmod("/home/dannym/blah1/blah2", "u+rw")

*** move files ***
mv(....)
mv(....)
mv(....)

for s in saved_state: chmod(convert_to_destination(s.name), s.mode)

If you get the idea ;)

Then the move would work even though some directories have "r--", which
happens all the time when I copy something from CD, maybe a
misconfiguration from my side though. (about 1/3 the files I "rescued"
had these directory-no-write permissions here O_O)

It also would help for the case of disabled directory user-read, but I
can't think of any real-world case where that would happen :)


> 
> > 
> > 9) not having the size of the contents of each folder, I managed to fill
> > up my backup partition all the time because I just didn't know on a whim
> > what size the folders were... (yes I know about the "calculate size"
> > menu item)
> 
> Having to do a "du -s" on each folder would slow xffm down, even more
> than all the gtk2 overhead has already. 

Yes, doing it *all the time* would... But a "I want to know what big
bunches of stuff are in *this* specific directory" ? (yes, still slow,
but it would be faster than me going to the terminal and doing the same,
since I'm slow ;))

Then again, maybe this is better implemented in a seperate program...
dunno...

> > 
> > 10) there is a "scp before rsync" option which implies that scp is
> > supported, but how to connect to a host via scp using xffm ? :)
> 
> Say you open xffm on box 1. Then you ssh to box 2 and open xffm on box 2
> but on the same display. Now you have two instances of xffm running on
> different machines. If you drag and drop from one to the other, copying
> will be done by the receiving box by either:
> 
> scp-before-rsync   rsh-before-ssh
> yes                  yes  --->  rcp
> no                   yes  --->  rsync --rsh=rsh
> yes                  no   --->  scp
> no                   no   --->  rsync --rsh=ssh
> 

Hehehe that's cool ! :)
*tries*

> The reason for flexibility is that depending on the platform and
> configuration of the boxes one method might work better than another.
> Definitely YMMV with each method.
> 
> regards
> 
> Edscott

cheers,
  Danny