On Thu, Sep 27, 2012 at 8:34 AM, Nimit Shah <nimit.sv...@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 <lem...@gmail.com> wrote: >> >> El Sep 27, 2012, a las 1:28, Emmet Hikory <per...@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@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@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@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
