Ticket #71 (new defect) — at Initial Version

Opened 16 years ago

Last modified 11 years ago

savannah: Skip vs. Abort on multi-file/dir operation

Reported by: slavazanko Owned by:
Priority: major Milestone: 4.8.1
Component: mc-core Version: master
Keywords: Cc: m-c.org@…, zlatko-m-c-org@…
Blocked By: Blocking:
Branch state: merged Votes for changeset:

Description

Original: Skip vs. Abort on multi-file/dir operation

Submitted by:Thomas Zajic <ZlatkO>Submitted on:Sat 16 Jun 2007 08:47:06 AM UTC
Category:CoreSeverity:3 - Normal
Status:ConfirmedPrivacy:Public
Assigned to:NoneOpen/Closed:Open
Release:current (CVS or snapshot)Operating System:GNU/Linux

Discussion:

Sat 14 Jul 2007 09:27:33 PM UTC, comment #1:

can confirm this bug in cvs, 4.6.1 or 4.6.1 + patches.
it only works if the complete tree is 755, otherwise they are 
unlinked without notice - however that works

i am working on a patch to support skipall, it might be possible i 
could fix that too.
but looking at the code i worry about recursion :)

its on line 1356 in file.c (recursive_erase)
the returnstatus gets abused and therefore lost unless it is a 
FILE_CONTINE:

1346: return file_error if != FILE_CONT
1328: return_status = file_error != FILE_CONT
1338: return return_status

the operation in line 1328 seems to be the odd one, but i cannot 
fully understand its working:
return_status =
(recursive_erase
(ctx, path, progress_count, progress_bytes)
!= FILE_CONT);

is it to end the while loop on abort?

besides the fact skip is ignored completely this should be a clean 
path before adding skip (&skipall)?

thanks for i|o
	me <me4mc>
Sat 16 Jun 2007 08:47:06 AM UTC, original submission:

When mc encounters an error (eg. permission denied) while operating 
on multiple files and/or directories (eg. move, delete), it presents
an error dialog stating the problem and offers "Skip, Retry, Abort",
 which is fine.

However, if you chose "Skip", it actually does the same as if you 
had chosen "Abort", ie. it cancels the whole operation instead of 
actually skipping the problem file/directory and going on with the 
rest. This is especially annoying if you want to delete a huge 
directory tree which happens to have a few files strewn in that 
belong to a different user.

To reproduce, copy a directory tree as a user, change a few file 
ownerships and permissions somewhere within the tree, then go back 
to the top of the directory structure and hit F8. This has been 
bugging me for a while already, and I just stumbled across it again 
when I wanted to delete the thunderbird-2.0.0.4 build tree, so I 
decided to finally report this bug. :-)

I'm using the release version of mc-4.6.1 with a couple of Uhulinux 
patches from Egmont Koblinger (all of the UTF-8 patches and a few 
other ones).

[zlatko@disclosure]:~$ mc --version
GNU Midnight Commander 4.6.1
Virtual File System: tarfs, extfs, cpiofs, ftpfs, fish, mcfs, undelfs
With builtin Editor
Using system-installed S-Lang library with terminfo database
With subshell support as default
With support for background operations
With mouse support on xterm and Linux console
With support for X11 events
With internationalization support
With multiple codepages support 
Note: See TracTickets for help on using tickets.