On Tue, Aug 4, 2015 at 5:11 PM, Magicloud Magiclouds <magicloud.magiclo...@gmail.com> wrote: > Hi, > > Say I am moving a file between two harddisks.
Now you know. You don't want to do that. (Although I just did that. It was a notebook, I knew the battery was good, and I was only mv-ing, uhm, well, it was more than one file. I was doing it for the thrills. I got lucky. I think. Come to think of it, this may have something to do with why X11 didn't work afterwards.) If you have a small number of files, are really sure you won't lose power or hit some OS error, and know you have no hard links or symbolic links or file:/// urls in anything, mv should do the job. But if something happens, it does leave things in a partial state that you then have to figure out. At least, for a single file, current implementations of mv that I am familiar with, if the source and destination are on different file systems, mv copies and then deletes the source. (Deleting the bytes from the source of a single file as you copy them to the destination requires so much juggling it's generally not considered worth it. It is done in some special utilities that you probably have never used.) cp is better equipped to handle some corner cases, but it's a little hard to understand what you are doing with the options about soft and hard links. The big advantage is that you, yourself, delete the source after you are (pretty) sure the cp completed successfully. tar and rsync are more likely to produced the desired results, in no small part because you have to think out what you are doing. (The magic underlying drag-and-drop on the Mac OS is not insignificant, and even that is by no means foolproof.) > Both filesystems are Ext4. > During the operation, I cut off the power. I assume that you mean you lost power. If not, you're asking the wrong question. > Then boot the host, and fix the > filesystems. filesystems are designed to be somewhat robust against accidents. Not so much against deliberate abuse. Power dying in the middle of a raw mv is one thing that is basically impossible to guarantee results across. > Now, I see in both locations, there are the file. My question is, is it safe > to remove file in dest, and move to it again from src? I would not do that. I would first use cmp to see if the destination and result are the same. If the files are the same, I would only have to check one file. If different, I would have to look at both. Then I would have to make a judgement call as to what to do with the two pieces. That's not something you want to have to do. (hexdump -C can be of use if the files contain only 7-bit ascii and some minimal arbitrary binary data. If there are Chinese or such multibyte characters in the file, you may have to find or write a special dump utility. I have written such a utility for shift-JIS characters. It took me something like eight hours across several days, not including the time it took me to write the ctype library, which was more than 40 hours across several months. If you want the source, I'll post a URL, but can you read C? do you understand the structure of your character encoding? are you willing to walk through understanding the bizarreness of shift-JIS? ...) In short, don't do that. It hurts. At minimum, cp, then rm after you check the copy. Better to learn and use tar, rsync, and/or other similar tools. > Thanks. > > -- > 竹密岂妨流水过 > 山高哪阻野云飞 > > And for G+, please use magiclouds#gmail.com. -- Joel Rees Be careful when you look at conspiracy. Arm yourself with knowledge of yourself, as well: http://reiisi.blogspot.jp/2011/10/conspiracy-theories.html -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAAr43iN9XoUJL9O+5GqcSmRdNOyF-8R8EQ8-=uCEQmOzjtD=w...@mail.gmail.com
