xffm issues

[Danny]

Hi!

Am Son, 2003-08-17 um 16.34 schrieb 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.

Uhm, well yes, but the move cannot succeed at all, then ? So why start
moving in that case anyways? Or did I miss something?

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

Hehe, the fundamental thinking weirdness I am having is that a directory
is the subtree starting at a position, including the nodes going deeper,
content (includes subdirectories with content too, ...). 

like, "the" directory "x" "is":
x
+- a
|  |
|  +-b <-- file
+- c
|  |
|  +- d
|     |
|     +- e <-- file
+- f <-- file

(I hope that ascii picture is readable ^^)

But it seems I'm the only one thinking like that :)

Now for a file, I can move a file regardless of its permissions. If it
is readonly, I can still move it. And everything contained "in" it.

And a directory is a special file (yes, yes, "containing other files
[implies...'special files']", theoretically speaking). 

Now, I *can* move a directory if it is write-protected.
But I cannot move its files, because the directory is write-protected.

The result is, part of the original is still in the source, although I
said "move this directory", it was partially moved, partially copied. it
kind of split up what I think of being one thing, created duplicates.

imo it would be even better if it gave an error message saying "I can't
do the move" and changing nothing in the filesystem instead of doing it
like this ;)

Why it happens technically is probably this: [just for clarification]
first the merry copying... then the copying is finished. Let's do the
deletions.
BUT
Because one directory was not empty, it could not be removed after
copying. That was because it still contained files. Which it did because
the files could not be deleted, which is because the directory was
write-protected. Removal of directories continues to fail in several
layers of parent directories, now for 'both' reasons "there is still
content because there is a directory which still contains some files,
weeeird" and "there is still content being a directory containing
nothing except a directory [which still contains something], weeeird"
...

Now if the target disk gets full ontop of that, the whole "move" stops,
some files in the source directory are gone, some files in the target
directory are incomplete, and I'm confused and wonder what to do.

[which brought me to the "update by default" option suggestion]

You see why I'm confused when thinking like that ? ;)

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

A sec... You mean if I intend on moving a directory, it's *parent*
directory should not be write protected... I agree, but does "moving a
directory" not imply "moving its content", whatever that content is ?

What I am thinking like: move a directory including its data, by some of
the data *within* "coincidentially" being a write-protected directory,
it fails. I'm like *boom* eeek what was that hitting me right on the
head ;)

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

Aha aha :) Dunno that command yet :)

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

You are right, what I am doing is backing up... but what I'm getting at
is the general way of moving something, which I think is quite similar
to "back up source", "cd destination", "restore".

That it is implemented as "copy source destination", "delete source", is
just a detail of the real world. It is not even like this as long as
source *and* destination are on the same mount point.

If source and destination are on the same mount point, the move of a
directory works regardless on if there are other write-protected
directories *in* it or not.

Why the discrepancy?

> > 
> > > 
> [...]
> > 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.
> [...]
> workdir by asking "Extract into" and making the command queued (no other
> "queued" autotype function will proceed until this one has finished).

Ahaaa ? Cool, queueing... muhahaha :)

I found something:
I used dnd to move a big big directory from xffm window 1 to xffm window
2.
xffm window 2 was processing that (as indicated by the progress bar
there ;))

Now I thought, hm, since xffm window 2 still reacts, maybe it will also
listen for me to say what it should do next.

Going to xffm window 1, next directory, dropped onto xffm window 2 on
the appropriate location. It didn't say anything, since it was still not
done with move number 1.

time gets eaten...

move number 1 finished... [more or less, sometimes]

*all done* 

Uhmmmm? Where did move number 2 go ?


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

Cool :)

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

Hehe, will see, will see. But that would also require xfdu to be
included somewhere in xfce for the menu entry to be useful. Which
"ideally" would require me to implement it in C. But it is already that
convoluted in python, so in C *shudder*

> 
> regards
> 
> Edscott

cheers,
   Danny