I moved files into a .... file and can't access them anymore :)

Hi all

I used the function movefile (MATLAB 2018a). My file name is stored in the variable filename.

I run the lines

mkdir('folder_name')

movefile(filename,'folder name')

as a result MATLAB copied some files into that folder... the problem is: that is not a folder but still a file!

due to a typo in the second command (missing underscore), MATLAB created a new file (instead of using the folder name I previously created) and copied some files into it (I can see the size of the file/folder). I tried to change the attributes of the file (to make it into a folder) but I can't, I also tried to open it with explorer or winrar but it does not work. Is there a way to solve this without losing the files ? I have already tried to copy those files out of the fake folder but MATLAB tells me it can't find the file names

[DGM]

If you move file A to file B and then move file C to file B, file A is gone. You overwrote it. I would assume you could verify this if you looked at the contents of the file and compared that to what the last file moved should be.

I'm assuming that this is something that's being done in a loop. I don't see anywhere that an output filename and path are explicitly being created. If you're relying on the file handling tools to implicitly do that, you're leaving yourself open for mishaps like this.

Whether those files can be recovered, I don't know. I haven't touched windows in years.

[dpb]

@DGM is correct -- you've overwritten all except the last file; the rest are, unfortunately, gone.

By having used movefile instead of copyfile, the internals of the MATLAB function have--

1. copied the original file to the target file, and then
2. deleted the original as requested.

Unfortunately, since this was done with the command line tools and not the GUI user interface in FileExplorer that gives one the opportunity to have deleted files not be permanently deleted but just moved to a discard folder, that action didn't happen and the OS did as directed and did delete the files permanently.

Too bad, lesson to be learned is to be sure to debug any script/function thoroughly before relying on it to make irrecoverable changes. In cases such as this, this usually means making backup copies of the originals and having them stashed away somewhere safe before running the script/function. Having failed to do that, unfortunately, you have lost those data.

[DGM]

Idk about windows, but at least in linux, if all else fails, one can use low-level methods to scrape up deleted files. It's not fun, and success is dependent on the amount of disk write activity after the deletion. You'll end up with a huge pile of unnamed, unknown chunks of data that used to be files. Maybe some of the ones you want are still there, and maybe they're still in one piece, but there's no guarantee.

Any sort of backup would be much easier and safer than dealing with that, but I figured I'd throw that out there. I'm not too proud to admit that I've nuked myself too.

[dpb]

I've done the above on Windows, but not with a recent incarnation; only in pre-Win7 days through NT. I presume there are still some tools available, but as your comment notes, it's definitely not for the faint of heart and uninitiated. If one thinks there's a chance having done what OP did that somehow the target file could have yet contained all the files somewhat like a directory, there's insufficient understanding of file systems to have much chance of success even if gives it a go.

Hopefully the files are able to be reconstructed without too much effort...if they were truly one-of-a-kind and valuable, it may be time to hire outside help.

[Walter Roberson]

undelete programs for Windows still exist.

[Jan]

Recuva is a free tool for searching the contents of deleted files. If it runs directly after the deleteing, there are good chances to recover the file. Installing the tool after the accident is a bad idea for this reason.

The general rule is: Data, which are not stored in a backup, are not important.

@LO: Your files are gone. ;aybe you can find them or parts of them by tools for undeleting files, but this is fragile.

[LO]

thanks

everyone. I don't think the data are so important to try using recuva or some Linux utility.

I wonder... if the file was overwritten... wouldn't be enough to rename it and add the proper extension ? maybe I am too naive... I will give it a try later.

Thanks all anyway :)

[Walter Roberson]

Renaming the file and giving it any proper extension, would rescue only the very last file that you movefile() into place. All of the other ones are gone :(

[dpb]

Of course, the filename extension is immaterial to the content of the file; all that happens is that automagic recognition of the file type by the OS or MATLAB functions such as readXXX that look at the extension to identify the file content type won't work.

It's common practice to not add extensions to directory names, but there's nothing sacred about that convention, either.

[Walter Roberson]

There are matlab functions that rely on file extensions.

[dpb]

"... or MATLAB functions such as readXXX that look at the extension to identify the file content type won't work."

Transparently, at least. Most of the new ones have a named parameter as optional input to let the user specify the data content type if the extension is missing or not a recognized one. Some of the older functions may not have such flexibility, but I haven't thought about who those might (or might not) be.

Of course, if try to use the "UseExcel" option, then MS Excel itself will barf if the file extension doesn't match, but that's not MATLAB, per se.