LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Programming (https://www.linuxquestions.org/questions/programming-9/)
-   -   moving files from a location to other, preventing to move incomplete files (https://www.linuxquestions.org/questions/programming-9/moving-files-from-a-location-to-other-preventing-to-move-incomplete-files-683150/)

pogo123 11-13-2008 09:42 AM

moving files from a location to other, preventing to move incomplete files
 
Hi:

OS: Ubuntu Intrepid Ibex

Need help in moving files from location 1 to location 2, in linux, using some sort of code in order to avoid moving incomplete files. The funtion needs to be recursive in order to continue trying to move the file and do so as soon as possible.

As an example: when using the unrar function in a rar password protected file, the process will extract the file before asking for the password, the file is completely extracted and for a second or two stays in the directory completely available, after that the unrar program then ask you for the password and begins to erase the file. What I am trying to accomplish is to exploit this weakness in the process in order to move the files before the unrar routines is able to destroy the file.

Thanks in advance for your help in this matter.

Tinkster 11-13-2008 01:58 PM

Can you please elaborate on the WHY? I find this idea
very dubious indeed....



Cheers,
Tink

pogo123 11-13-2008 03:34 PM

ok
 
very well, lets forget about the rar proc... any ideas on how to accomplish the process.

just for the sake of trying to help a fellow member :)

pixellany 11-13-2008 04:14 PM

I do not understand this---what do you mean by moving an "incomplete file"? How would--eg--mv know the file was incomplete? If a process has a file open for writing, I'm not sure mv will move it at all.

You could experiment with dd, but to try to do things with a file as it is being written could give some very interesting results.

And---when you decline to say WHY you are doing something, you'll turn off a lot of potential help.

unSpawn 11-13-2008 04:54 PM

Quote:

Originally Posted by pixellany (Post 3341117)
Iwhen you decline to say WHY you are doing something, you'll turn off a lot of potential help.

Should be clear, right?:
Quote:

Originally Posted by pogo123 (Post 3340687)
the process will extract the file before asking for the password, the file is completely extracted and for a second or two stays in the directory completely available (..) exploit this weakness in the process in order to move the files before the unrar routines is able to destroy the file.

*Very* doubtful this will work the way he perceives it will work and since this is circumvention I strongly doubt we should be aiding in any case.

estabroo 11-13-2008 07:07 PM

Moving wouldn't do any good unless you moved it to a different filesystem/partition (in which case its a copy) because it'll retain its inode and the original process will go on accessing/writing/unlinking with no problems.

For the general problem an easy solution is to have the creating process also make a checksum file (md5, sha, ...) when its done, so you not only know when the file is complete you can also verify your move/copy against the checksum file.

ta0kira 11-13-2008 10:59 PM

Why not just hack the unrar source code?
ta0kira

comm2k 11-14-2008 05:46 AM

The file is not decrypted - there is little point but anyway you should look into inotify tools - wait for "close write" event and then trigger mv.

There is nothing dubious but also nothing useful in this approach.

i92guboj 11-14-2008 06:21 AM

Quote:

Originally Posted by comm2k (Post 3341669)
The file is not decrypted - there is little point but anyway you should look into inotify tools - wait for "close write" event and then trigger mv.

There is nothing dubious but also nothing useful in this approach.

That is the way to do what it wants: inotify.

However, as I said on the duplicated thread and as you also say, there's no point in doing so, such "vulnerability" doesn't exits. The files are encrypted, and can't be decrypted without the password. There's absolutely no way to get the original contents back without the password that was used to crypt it. You will only get an useless heap of bytes.

The only way to get the contents back is with a password.

And yes, there's something dubious. Breaking encryption is non-legal in some -or most- countries, even weak encryptions like DVD's (which is not the case here, since rar uses AES128).


All times are GMT -5. The time now is 02:29 PM.