Prevent deletion of file when it is being copied

[John Moser]

On Thu, Sep 27, 2012 at 8:34 AM, Nimit Shah <nimit.svnit at gmail.com> wrote:
> Haha :D
> I was removing the useless files and by mistake selected that file as well
> along with other files. The copy was going on in the background so had
> forgotten about it.

Unix has a proud tradition of assuming you're not a moron.  That's why
Unix tools don't complain when they do things right.  It's like

~$ rm -rf all_my_stuff/
~$

Because, hey, you asked to remove all your stuff.  What do you think
happened?  It's not like we need to ask for confirmation; you pressed
enter, didn't you?  Unless something goes distinctly wrong
(files/directories are immutable, no permission, etc)

I like that you can cut/copy/paste files around in Nautilus without it
going, "Do you want to place a copy of XXX here?" or "Are you sure you
want to move these files here?"  When you shift+delete doesn't it ask,
though?  (Which is silly, yeah; you hit delete, didn't you?  Of course
you want to delete these files!)
>
> Nimit Shah,
> B Tech 4th year,
> Computer Engineering Department,
> SVNIT Surat
> www.dude-says.blogspot.com
>
>
>
> On Thu, Sep 27, 2012 at 5:42 PM, Luis Mondesi <lemsx1 at gmail.com> wrote:
>>
>> El Sep 27, 2012, a las 1:28, Emmet Hikory <persia at ubuntu.com> escribió:
>>
>> > Nimit Shah wrote:
>> >> While copying a file from my computer to external disk, I by mistake
>> >> shift+deleted the file. But still the file transfer dialog showed that
>> >> it
>> >> was continuing. At the end of the transfer it failed.
>> >>
>> >> Hence i request you to add a check for file transfer before deleting
>> >> the
>> >> file.
>> >
>> >    As much as this would be a lovely feature, I don't believe that it is
>> > something that we could implement in Ubuntu.
>> >
>> >    When copying a file, there are usually two ways to go about it:
>> > either
>> > open the entire file, and write it to a new location, or open a series
>> > of
>> > sections of the file, and write them each to a new location.  There are
>> > a
>> > very large number of programs that provide both of these mechanisms in
>> > the
>> > archive.  In the majority of cases, the first potential solution is not
>> > used, because it limits file copies to files that fit entirely in memory
>> > (with everything else), and requires a longer-running algorithm, but
>> > when the second method is used, the file cannot be allowed to be deleted
>> > before the file transfer is confirmed as complete.
>> >
>> >    When deleting a file, the usual practice is to remove the reference
>> > from the directory definitions (unlinking), leaving the underlying
>> > filesystem
>> > to manage recovery of the newly available space.  Again, there are a
>> > vast
>> > number of packages in the archive providing programs that do this.
>> >
>> >    In order to implement the feature you describe, we would have to
>> > either
>> > provide some systems interface that traps all calls to unlink() and
>> > checks
>> > some external reference to determine if it is being copied or patch all
>> > software that could potentially delete files to check the reference,
>> > whilst
>> > simultaneously patching every package that provides a means to copy a
>> > file
>> > to populate this reference during the file copy, which would make all
>> > such
>> > operations considerably slower, with potentially massive impact on
>> > server
>> > capacities, interactive response times, and battery life.
>> >
>> >    Further, it is unlikely that the developers and maintainers of most
>> > of
>> > the software in our archive would be willing to accept such patches,
>> > given
>> > the potential complications and incompatibilities with other systems,
>> > such
>> > that the result of this vast undertaking would require considerable
>> > ongoing
>> > development effort to port these patches for each new upstream release.
>> >
>> >    Lastly, in the event that any of the programs providing file copy
>> > functionality were to crash, they may not properly clear the reference
>> > indicating files whose deletion need block on the transfer completion.
>> > As a result of such a crash (or any other bug when updating references),
>> > a user's system may end up having any number of files that cannot be
>> > deleted without manual intervention into the file transfer reference.
>> >
>> > --
>> > Emmet HIKORY
>>
>> Usually there are 2 solutions to these types of problems:
>>
>> 1. develop some complex code to deal with it
>> 2. don't do the action to begin with
>>
>> Typically # 2 is the best answer. Writing complex code to avoid something
>> that's obviously the wrong thing to do by the end user seems silly. The
>> users simply have to wait until their files are copied. Why would you delete
>> the file by shift-delete while is being copied!?
>> --
>> Ubuntu-devel-discuss mailing list
>> Ubuntu-devel-discuss at lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
>
>
>
> --
> Ubuntu-devel-discuss mailing list
> Ubuntu-devel-discuss at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
>