Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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$ 
share|improve this question
    
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 4: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 1 '11 at 23:36

2 Answers 2

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. :-)

share|improve this answer
    
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 2:00
    
Yes, no reply. :( But they will eventually get around to it I suppose... –  ptrcao Aug 30 '11 at 3: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 2 '11 at 8:05

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...?).

share|improve this answer
1  
    
    
Heh, that takes me back. Xenix... Sync, wait for HDD LED to dim. Repeat two more times and call for system halt. Does anyone still sacrifice chickens on the keyboard before starting any major updates? –  Fiasco Labs Jan 24 '12 at 4:19

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.