10

I was at uni a few days ago when I attempted to cut and paste a 500Mb file (a 3gp video recording) into my H drive on one of the uni network's Linux (Debian KDE 3.5) computers.

I did not see any error messages indicating the cut-and-paste job had failed, but when I looked at the resulting pasted file, it appears now as a 60Mb file (that's a 440Mb discrepancy!). My file was somehow shrunk! Did the file get broken up in the process of pasting it and this is the fragment of an incompletely copied file?

I suspect what happened was the file transfer was interrupted due to H drive size-allocation limitations imposed on users by administrators.

But you'd think Linux would anticipate that the file was bigger than would be possible to move to the intended destination and abort the transfer before it begun, not wait till it reached some forbidden limit then cancel discretely without notifying me.

Also in the event of an interrupted file transfer, one normally expects the original file to be remain intact (i.e. not deleted) the original USB drive?

The file appears in the destination, but is now much smaller and is non-functional. The original file in the source location on the external drive has disappeared, suggesting the job was completed successfully.

This resizing is rather bizarre and now I don't seem to have access to the original file. After cutting and pasting the original may have been removed from it's source location. The computer has mishandled this task, apparently causing me to lose my file, and I would like you to help me to retrieve my file.

I have tried recovering the file on my phone's SD card using PhotoRec and Sleuthkit forensic tool. No luck. Deleted sections of the disk may have been overwritten by new data. So zero progress on the source end. Any way to recover on the destination end (i.e. my uni network)?

peter@peter-deb:/media/E0FD-1813$ cd DCIM/
peter@peter-deb:/media/E0FD-1813/DCIM$ cd ..
peter@peter-deb:/media/E0FD-1813$ cd LOST.DIR/
peter@peter-deb:/media/E0FD-1813/LOST.DIR$ ls
peter@peter-deb:/media/E0FD-1813/LOST.DIR$ ls -a
.  ..
peter@peter-deb:/media/E0FD-1813/LOST.DIR$
ptrcao
  • 5,635
  • What did you use to copy/move the file? Also, how would you expect any copy tool to know what the sys-admins set as maximum allowed file sizes? Also, are you sure that there wasn't finger trouble from your side? No copy tool should ever delete the original file if the copying isn't finished. – tshepang Aug 27 '11 at 04:19
  • The copy tool was Konquerer or whatever the file manager was on that KDE 3.5 Debian computer. I'm sure I didn't dislocate the usb plug in the duration of the transfer job if that's what you mean? – ptrcao Aug 27 '11 at 10:26
  • ptrcao, After doing the transfer, have you: ( unmounted the USB drive ) or ( used eject/remove option and waited for a pop-up saying you can safely remove it ) ? – rozcietrzewiacz Aug 30 '11 at 15:14
  • Yes, that is a matter of habit. The only reason I wouldn't do that is on some networks, the feature isn't enabled within the desktop environment, but I seem to remember this feature being available and routinely used by me on the Linux network in question. So what does that tell you? Anything helpful? – ptrcao Aug 31 '11 at 12:00
  • 1
    "H drive": I would bet the culprit is on the windows side and has nothing to do with linux, network, or server. Window's SMB seems to have some problems like this as it attempts to buffer files internally and unlink the original (during a 'move') prior to finishing. – Jonathan Cline IEEE Sep 01 '11 at 23:36
  • ptrcao, I didn't see your reply because you didn't '@' me. What I was guessing is that the unmount could have been unfinished because data was still being read from it - and by a very unfortunate event, the file entry on USB filesystem got corrupted in the process - which lead to it being not visible in the future. In that case, you might find (a part of) the file in lost+found folder after doing fsck on it. – rozcietrzewiacz Sep 02 '11 at 16:57
  • @rozcietrzewiacz I hope you're right, but is your theory consistent with the result that the destination file was of a reduced size, and that the original was deleted, suggesting the transfer was perceived by the computer to be complete and therefore it removed the original? – ptrcao Sep 02 '11 at 17:04
  • Yes, what I am suggesting is that the file might have not been deleted, but got corrupted due to incomplete unmount operation. Try fsck and then do file lost+found/*. – rozcietrzewiacz Sep 02 '11 at 17:08
  • @rozcietrzewiacz The file is called VIDEO0056.3gp, the most resembling directory I could see in the disk was /media/E0FD-1813/LOST.DIR/ I tried substituting these into your command but it was not recognized? – ptrcao Sep 02 '11 at 17:16
  • I'm not sure what you mean. It is a FAT filesystem? Not sure if fsck can help then. Does the folder contain any files? – rozcietrzewiacz Sep 02 '11 at 20:42
  • @rozcietrzewiacz It is FAT16. fsck doesn't apply then? When I navigate to the folder in Nautilus, and even after displaying hidden files, no, I cannot see anything in that folder LOST.DIR... – ptrcao Sep 02 '11 at 21:45
  • let us continue this discussion in chat – rozcietrzewiacz Sep 02 '11 at 22:06

2 Answers2

11

First, never move a file across the network, only copy. You can always delete the original after the copy has been successfully completed. Secondly, your local system might not even be aware that a filesystem quota exists on remote storage - don't assume that it's even possible to guess ahead of time whether a copy operation would fail due to a remote quota. As far as the "sending" process is concerned, all bytes were sent to and received by the remote end, and you wanted to move the file so now the original can be deleted - poof file gone.

"Any way to recover on the destination end?" - not a chance. OK, maybe a small one. Check with the network admin to see if just maybe the system actually received the full file but only reports back to you the size within your quota. Don't hold your breath.

And I apologize if I'm sounding a bit harsh, but it seems like some new habits are in order. :-)

Kevin
  • 40,767
shon
  • 111
  • No... :( How could the administrator not have guarded against this? I'm just a regular student, what do I know about computers and networking and good data management practice... You have provided a glimmer of hope. I have put in a request and opened up a case to see if they can recover my file. Any further helpful, practical suggestions, things I can do, or ask to have done for me? That file was important and unique! I needs it... :( – ptrcao Aug 27 '11 at 10:31
  • Also, I actually tried to copy the remnant file and execute it at home. In fact, it is reported as a 60Mb file by all computers that view it, and in fact that file is not functional. Does that rule out your hopeful scenario? – ptrcao Aug 27 '11 at 10:35
  • Have you spoken to a system administrator? That's the only shred of hope left. – shon Aug 30 '11 at 02:00
  • Yes, no reply. :( But they will eventually get around to it I suppose... – ptrcao Aug 30 '11 at 03:24
  • The lazy administrator dismissed it in a second and said he wanted to close the case. It was instantaneous. After all the detail I put into my case, he didn't so much as bother with it... – ptrcao Sep 02 '11 at 08:05
  • There is a difference between lazy and recognizing a WOMBAT. – Fiasco Labs Jan 24 '12 at 04:21
1

Old school solution for next time:

# sync
# sync
# sync
# umount /mnt

(This is somewhat sarcastic because the three sync's in a row are legacy and half superstitious. Look it up. http://utcc.utoronto.ca/~cks/space/blog/unix/TheLegendOfSync )

It was useful in the SYSV days.

Ok, took me quite a while to locate this on google. (Why so hard? Folklore getting lost?) Anyway I suggest the youngin's to read Raymond's Unix Folklore book (which... I can't find on Amazon...?).

Jonathan Cline IEEE
  • 109