Prevent deletion of file when it is being copied

Nimit Shah nimit.svnit at gmail.com
Thu Sep 27 12:34:15 UTC 2012


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.

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-devel-discuss/attachments/20120927/01343524/attachment.html>


More information about the Ubuntu-devel-discuss mailing list