xffm issues

[Danny]

Hi!

Am Sam, 2003-08-16 um 15.54 schrieb edscott wilson garcia:
> Hi Danny,
> 
> On Sat, 2003-08-16 at 02:29, Danny wrote:

> > 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)
> > 
> 
> Sounds good. And fairly easy too. It could probably be added as a
> "hidden" option and in 4.2 become unhidden (since it would requiere
> translations).

Hehehe :) yay


> > > 
> > > > 
> > > > 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:
> > [...]

> A couple problems with this approach. 1) What if the volume is write
> protected? (as a cd or a ufs or ntfs mount in linux). 2) If a directory

1)
The destination folder ? Impossible.
The source folder ? Then one can't move files away from there anyways.

> has a read-only status, it should be respected because the status is
> there for a reason. If there is no reason for write protection, then it
> should be changed, permanently. What is needed is a specific "chmod"
> function, capable of doing "chmod -R u+w" or "chmod o-x"  or whatever on
> the selected files. This in turn requires a dialog and translations,
> which leaves it pending for 4.2. 

Yeah, the read-only status *would* be respected, as it would be restored
after the move. I just think of moves as "moving small trees as-is onto
another disk/etc" (as this is what I am doing currently ^^).

But as it is now, I cannot move f. e. the whole tree "blah1" to
somewhere else just because some directory *in* it is write-protected
(as if I wanted to write something in there... it should just go away
after I'm done with it ;))

On the other hand, if I do the whole thing with 'tar cp * |(cd
/wherever; tar xp) && rm -rf *' ; the rm fails on readonly directories
too, which I always found weird... but at least it fails consistently
all over the place, if that is what you mean :)

But you are right, batch-changing of permissions surely will help,
though making a good gui for that will be a challenge ;)

And, I first have to *know* some directory in this directory I am moving
is read-only (and why would I remember, because even if I made it
read-only myself, this doesn't mean I don't want to be able to move it
somewhere else ^^)

> 
> The "disk usage ctrl-Y" will give you number of files and filesize for
> this purpose. It takes longer than plain "du -s" because it opens a
> pretty dialog to show progress. The result is displayed in the xffm
> status line.

Yes, though only for one item and not: in sorted order, for each item of
a directory, be it a subdirectory or a file :) I really think I'll make
a small external proggy in python for that :D

Which leads me to a question before I even start: is it possible to add
some own programs to the xffm context menu of folder nodes ? ;)

(I could think of using it for "compression", "image viewer" and "size
statistics" right away)

> 
> regards
> 
> Edscott

cheers,
   Danny