Re: Prevent deletion of file when it is being copied
On 27/09/12 06:28, Emmet Hikory wrote: 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. If a process on linux has opened a file (but not necessaries read it all into memory), and that file is then unlinked by rm or anything else, then the file should still be readable on disk until the process closes it. see http://www.barricane.com/undelete-open-file-from-inode for an example of undeleting a file with this method. this makes me think that this should just work (for the case of copying a single file with nautilus). for copying multiple files, relying on this, would mean that you would have to open (but not read), all the files at the start. this could hit limits of the number of open files when copying many files also, could this be done through file locking? it looks like linux might have the low level stuff needed to implement this. http://en.wikipedia.org/wiki/File_locking#In_Unix-like_systems also -- 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
Re: Prevent deletion of file when it is being copied
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
Re: Prevent deletion of file when it is being copied
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 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
Re: Prevent deletion of file when it is being copied
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:
Re: Prevent deletion of file when it is being copied
Luis Mondesi wrote: 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. While often asking users to perform other actions can help with this sort of thing, we can certainly try to help users avoid making mistakes. I'm not sure how in this particular situation, given the vast number of tools that copy or delete files making it potentially risky to suggest that the problem is solved, but generally if there is a technical solution that can be done *once* to save every future user the effort of learning any given lesson, this represents a vast savings in the total human effort involved, and is hence a clear benefit. Why would you delete the file by shift-delete while is being copied!? While I'm not familiar with the details of the situation that started this thread, a possible answer to this question could be demonstrated by the following story: Alice and Bob share a laptop, and they find it convenient to have a single account for both of them, and use different workspaces to run their different programs. One morning, Alice decides to copy her collection of found audio recordings to their new network-enabled stereo. In the afternoon, Bob is using his workspace, and discovers that there is not enough disk space for the video he shot the day before, and asks if he can remove anything. Alice, being sure that she copied the files hours before, suggests her found audio files, which had yet to complete delivery over their home network. Bob knows that simply removing the file from a directory will not free space on the hard drive, so uses a shortcut to ensure that the contents are purged upon deletion, freeing up the space for the video clips. As Bob is using his workspace, rather than Alice's, he will not see the ongoing file transfer, so not be warned that what he is doing is potentially dangerous. Yes, this is contrived, etc. On the other hand, I suspect many of us have managed to be both Alice and Bob in a scenario much like that above when interrupted in the middle by some significant distraction, or just a sufficient span of time. -- Emmet HIKORY -- 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
Re: Prevent deletion of file when it is being copied
On 27/09/12 07:51, Emmet Hikory wrote: Yes, this is contrived, etc. On the other hand, I suspect many of us have managed to be both Alice and Bob in a scenario much like that above when interrupted in the middle by some significant distraction, or just a sufficient span of time. It is contrived, but still possible. A (perhaps) simpler scenario is: * have multiple SSH sessions going; * have the correct amount of interrupts on what you are doing, requiring you to open (a few) more SSH sessions; * run the 'rm -rf whatever' you intended to run in a different SSH session. Pretty much all of us that work on multiple systems have done something like that at least once (not necessarily with 'rm'). On another track, Nautilus already has a seatbelt on: by default, deletion is actually move-to-trash. Of course, one can disable it. I wonder if this was the case for the OP. Cheers, ..C.. p.s. Emmet! Glad to see (ah, read) you! signature.asc Description: OpenPGP digital signature -- 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
Re: Prevent deletion of file when it is being copied
On Thu, Sep 27, 2012 at 09:51:58PM +0900, Emmet Hikory wrote: Yes, this is contrived, etc. On the other hand, I suspect many of us have managed to be both Alice and Bob in a scenario much like that above when interrupted in the middle by some significant distraction, or just a sufficient span of time. Not contrived at all. Unix, unlike Windows, is multi-user and concurrent. You must always, always assume that any two actions you can imagine might overlap in time and deal with those concurrency issues. It actually requires people who know what P and V are. ;-) -- 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
Prevent deletion of file when it is being copied
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. Nimit Shah, B Tech 4th year, Computer Engineering Department, SVNIT Surat www.dude-says.blogspot.com -- 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
Re: Prevent deletion of file when it is being copied
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 -- 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
Re: Prevent deletion of file when it is being copied
I think the problem that Nimit explains is only related to Nautillus. Am I right Nimit? Also you didn't said if the file you deleted was the source or the destination one? Regards, Nicolas 2012/9/27 Emmet Hikory per...@ubuntu.com 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 -- 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 -- Nicolas MICHEL -- 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
