xffm issues

[edscott wilson garcia]

On Mon, 2003-08-18 at 15:39, Danny wrote:
> 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?

Never underestimate what the user will try to do...

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

You sure make me feel your confusion ;-)

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

Programming flaw? I think I get your point. If the write protected
directory is part of the dnd selection, then do not erase, but if the
write protected directory is *inside* the one of the dnd selected
directories, then move it (preserving attributes). OK?

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

No where. Move to is processed by window2. There is no dnd queue. You
must wait till window 2 finishes. If you want to do another drop, do it
to window3 (separate threads).

regards,

Edscott


> 
> 
> > 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
> 
> 
> _______________________________________________
> Xfce4-dev mailing list
> Xfce4-dev at xfce.org
> http://moongroup.com/mailman/listinfo/xfce4-dev
-- 
edscott wilson garcia <edscott at imp.mx>