xffm issues

[edscott wilson garcia]

On Sat, 2003-08-16 at 09:32, Danny wrote:

> 
> > 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.

Why impossible? All I have to do is drop on a write protected volume.

> The source folder ? Then one can't move files away from there anyways.

That's what the read only mode of the source directory is supposed to do
as well...
 

> 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 ;))

AFAIK, if you intend on moving a directory, it should not be write
protected. That's the whole usefulness of write protection.

> 
> 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 :)

You could probably  do "chdir /src && mkdir /target && find ./ |cpio
-pmd /target && cd .. && rm -rf /src" to accomplish what you want.
 
> 
> 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 ^^)

For doing backup retrieval, cpio should be preferred over xffm because
it can also copy sockets, character devices, block devices, and
everything else that xffm is not programmed to do.

> 
> > 
> > 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)

If you want entries into the popup menu edit the libs/menu.c file and
add the entries in the static autotype_t autotype[] structure. No
problem if you add programs that do not exist. They will just not
appear. Benny put in the __linux__ directives but they are not really
required.

The format is:
{char *, char *, char *, char *, int (0|1)}
Which means 
{associated file extension,associated program, text for popup, text for
input of workdir, queued or not queued}

example 1:
{".lyx","lyx","LyX",NULL,0}
means for files *.lyx create "LyX" menu item under the open popup that
will execute "lyx" 

example 2:
{".tar","tar -xf ",N_("Extract files from"),N_("Extract into"),1}

has two additional entries which will make the input box request the
workdir by asking "Extract into" and making the command queued (no other
"queued" autotype function will proceed until this one has finished).

Queued instructions are executed one at a time, so you can queue a lot
of rpm -U or pkg_add instructions. (Queued is probably not the right
word because they are actually stacked).

You can also commit your changes to CVS since extra entries do not
affect the program.

regards

Edscott

> 
> > 
> > regards
> > 
> > Edscott
> 
> cheers,
>    Danny
> 
> 
> 
> _______________________________________________
> Xfce4-dev mailing list
> Xfce4-dev at xfce.org
> http://moongroup.com/mailman/listinfo/xfce4-dev