[solved] fileMove to rename turned folder into a "file"

[corgano]

Ok so I did a stupid. I was trying to rename a folder but I used FileMove instead of DirMove, and it turned the folder into a "file" that windows doesn't know how to fix. Doing the opposite, turning the "file" back into a folder with DirMove, does not work... How do I recover the folder?
 

FileMove("new folder", "new should be folder")

How do I undo this...

EDIT: SOLUTION
If you FileMove with a DIRECTORY instead of a FILE as the first param, it will move the first file in that directory. I didn't notice because the folder had only one file to begin with... derp. Just rename the file to its original name and carry on.

Edited December 24, 2018 by corgano

[TheXman]

Why don't you just delete the file and create a new folder?

[corgano]

That was an example, the "file" has a bunch of my photos in it. I know the data is still there because it has the right size. It even left the old folder behind.. But functions like FileSetAttrib don't let you set the D flag to tell the filesystem it's a DIRECTORY, and when I FileMove'd it, it unset that flag..

[TheXman]

Google >recover folder turned into a file<.  Looks like you may be able to recover some, or all, of your files using lower-level data recovery tools.  Good luck!

[corgano]

I was hoping that there was a way to like, binary read the file, change the flag in there, and then binary write a directory - or just change it directly - instead of having to copy ALL the files. It took 40ms to change the folder to a file, there has to be a faster way to change it back

How can fileMove even do that? Shouldn't it like.. check that it's moving files or something? 

EDIT: I tried using recuva, but it recovered the "file" and not the actual folder. Not sure where to go now.

Edited December 24, 2018 by corgano

[corgano]

Ran into a very stupid mistake I made that was a pain in the ass to undo, and I'm wondering if this behavior is intended

I was trying to rename a FOLDER, and I accidently did a FileMove( "path to a folder", "path to what you want to name it"). If I noticed my error, I would EXPECT it to throw an error, but what It did instead is happily accept the folder and write out a file with its contents...

Which is a bit of a problem. Not only is this an easy mistake to make, but windows provides no way to change files to folders. There's windows functions to set file attributes... which specifically forbid setting the D (directory) attribute, which makes it difficult to change back. When used on a FILE (trying to do the opposite mistake to undo the first one) DirMove("path of folder renamed to file", "name of a folder")  simply ignores the file.

This presents an inconsistency, either:
A: FileMove should be hard-coded to ignore directories, to prevent folder->file conversion
B: FileMove should REMEMBER the D attribute of a file / folder it renames and ensure the output has the same flag (set or unset) to ensure it can't change the D attribute of files / folders
C: DirMove should be modified to create the same behavior, so if you provide it a FILE it will write it as is as a FOLDER (set the D attribute to true)

Then you'd be able to prevent the issue, or recover from it.

[Melba23]

corgano,

Firstly, possible bug reports should be in Trac - but as we are here......

I cannot reproduce your event. When I try to FileMove a folder, only the first file in the folder is moved intact to the target path while the other files remain in the folder which continues to exist.

Please provide the exact command you used so that I can be sure I am doing as you did.

M23

Edit: I see you already had a thread running - threads merged.

Edited December 24, 2018 by Melba23

[careca]

I got the same result, FileMove('p', 'o') moved one of the files inside the folder p, and turned it into a file 'o' without extension, gave it an extension and the file is back, maybe there could be a check on the function fo prevent this, or create a single function for files and folders move/rename.

Edited December 24, 2018 by careca

[FrancescoDiMuro]

49 minutes ago, careca said:

or create a single function for files and folders move/rename

There are already:

- FileMove() should be used to move/rename files;

- DirMove() shouls be used to move (with all sub-directories and sub-files)/rename a directory.

[careca]

My point was that it would be nice to have only one function to replace both those.

[Jos]

23 minutes ago, careca said:

My point was that it would be nice to have only one function to replace both those.

To create even more confusion as they are now pretty self explanatory?   

Jos

[careca]

Or rather to simplify and reduce the number of functions and prevent mixups like the one presented on this thread.

 

[pixelsearch]

Remember that one ?

https://www.autoitscript.com/forum/topic/196667-question-how-to-delete-a-single-line/?do=findComment&comment=1410947

Unforgettable

[corgano]

11 hours ago, Melba23 said:

corgano,

Firstly, possible bug reports should be in Trac - but as we are here......

I cannot reproduce your event. When I try to FileMove a folder, only the first file in the folder is moved intact to the target path while the other files remain in the folder which continues to exist.

Please provide the exact command you used so that I can be sure I am doing as you did.

M23

Edit: I see you already had a thread running - threads merged.

Ok a bit of a derp here - the folder contained only one single large file. When it moved the file i wrongly concluded it moved the entire FOLDER. If I made this mistake on a folder with multiple items in it I (hopefully) would have caught on to what was happening. Renaming the file worked and i was back on my way, thanks

It'd still be cool to add either a note in the help file mentioning this behavior, or a check that the path is a file and not a directory. When you give DirMove a file, it does nothing, so giving FileMove a dir should also do nothing for consistency (as an anti-idiot measure)

[corgano]

9 hours ago, FrancescoDiMuro said:

There are already:

- FileMove() should be used to move/rename files;

- DirMove() should be used to move (with all sub-directories and sub-files)/rename a directory.

Actually a good point. Why do we have separate functions for the two? Is there some kind of benefit to it?

[FrancescoDiMuro]

@corgano

Benefits explained here

By the way, Merry Christmas! 

[BrewManNH]

2 hours ago, corgano said:

Why do we have separate functions for the two?

One is to move a file, the other is to move a directory, seems pretty self-explanatory to me. I wouldn't expect that using a function called FileMove would work correctly to move a directory when there's a function called DirMove. Why would you expect to move a directory with something that starts with File? 

That's like expecting FileRead to also read all the files in a folder, nonsensical.

[careca]

9 hours ago, corgano said:

II'd still be cool to add either a note in the help file mentioning this behavior, or a check that the path is a file and not a directory. When you give DirMove a file, it does nothing, so giving FileMove a dir should also do nothing for consistency (as an anti-idiot measure)

Exactly. 

@BrewManNH: Sure, but generally if the function doesn't work in a certain way it wont mess up anything else, maybe gives you an error flag or something, in this case, there could be just that, stating, "not  file" or "not a folder" depending on the function used. And if they were to be merged into one function, it would deal with whichever the case was.

 

[BrewManNH]

I agree that it shouldn't have moved the file without specifically being told to move the exact file, but I don't think that FileMove and DirMove should be merged, that makes absolutely no sense. The only bug in this function that I see is that being told to move a file, but being given a directory, it should have failed and reported an error and not moved the first file it found inside the directory.

The other bug I see, isn't in the function, but in the OP's code, trying to move a folder with a file command.Definite bad code.