AutoHotkey Community

Command: Filemove

Circs.: Windows sharing mp3s after using filemove. Files show up on other computer, but not accessible.

Conclusion: filemove fails to set some attribute on mp3 files that allows windowsnetworking to completely access those files.

How I found: I wrote a program that uses filemove or filemovedir, %dirpath%/ , %output% The files show up as expected but I cannot play on other computer, delete, or even copy these mp3s. If I turn off the sharing and reapply, they become accessible. SO, I thought this a windows problem. However, if I do a test filecopy, %a_workingdir%/*.mp3,%a_workingdir%/*-2.mp3 , then the new mp3 files can be listened to on other computer and copied/etc. SO, this MUST be a problem with filemove and filemovedir.

So, I am just going to have to filecopy into the shared folder and delete the originals, as the workaround.

Odd, problem.

Windows xp pro, sp3.

Yea I had the same problem Filemove Access Denied
After Lexikos's answer I tried moving the file using the comand prompt with the same result as AHK

Yeah Lexikos' answer in the other thread pretty much tells you the answer. It's not a bug with AHK, it's a feature of the NTFS file system. Try manually Copying some files (without AHK) - you should be able to access them from the other computer. Now try Moving (instead of copying) some files (again, manually without using AHK), you will probably find that you still cannot access them from the other computer, even when not using AHK.

For this to apply I have made some assumptions, so please forgive me if these assumptions are wrong:

I assume you are trying to move the files from one place on your computer to another folder on the same drive on the same computer (for example a 'shared' folder)? If this is the case, the permissions will stay the same as they were in the 'non-shared' folder.

I also assume that the NTFS permissions in the destination 'shared' folder are more relaxed (or at least different) than the source folder? Copying the files into the shared folder will mean that the files will inherit the 'more relaxed' permissions from the shared folder, whereas Moving the files will not.

Moving NTFS objects within an NTFS volume
i.e. moving a file/folder from one place to another on the same volume - PERMISSIONS STAY THE SAME AS THEY WERE IN SOURCE FOLDER

Moving NTFS objects between NTFS volumes
i.e. moving a file or folder from one NTFS volume to a different NTFS volume - PERMISSIONS INHERITED FROM TARGET FOLDER

Moving NTFS objects to a non-NTFS volume
i.e. moving from a NTFS volume to a FAT32 (or other file system) volume - ALL PERMISSIONS ARE REMOVED

Copying NTFS objects within an NTFS volume and
Copying NFTS objects between NTFS volumes
i.e. if you copy any files/folders between any NTFS drives - PERMISSIONS INHERITED FROM TARGED FOLDER

Copying NTFS objects to a non-NTFS volume
i.e. copying from a NTFS volume to a FAT32 (or other file system) volume - ALL PERMISSIONS ARE REMOVED

Or, a bit more succinctly from Microsoft:


See more info here

To get around this, you can either 1) move the files to a folder on another volume and share that folder instead, 2) make the permissions on your source folder the same as your destination folder and move the files, 3) Copy the files and delete them afterwards, or 4) use CACLS or something similar to change the permissions after moving the files over.

If you find that this does not explain your problem, then please can you give a bit more detail about what permissions you have set, and where the folders are (i.e. on the same drive, different drive, different computer), etc? Thanks

Probably correct. I just wish it was in chm, I would have used a filecopy and del origs. I now must find the original ahk, find the code and change filemove, then recompile, and test.

One thing that doesn't square is my permissions are same on source and destination.

Also, I just downloaded a podcast, and did a dos. "move bor.mp3 J:\squished\bor.mp3", and File was playable on network. I also did a cut and paste of another new mp3 with windows commander, this mp3 too was listenable.

Then, just to test again, I let a script do the move, and file was not listenable (fully accessible for read, copy or delete).

Agree with degarb a note about this "problem" should be added to the help file.
When I first found it I was

Just tested cacls b.mp3 /P Everyone:F

This works! The file is listenable after doing this, after script filemove. But it has a confirmation dialog. If I can't find the switch to turn off the confirmation, it would be tricky script to. I don't see recurse switches either so needs a for statement for simple batch, else I find ahk easier and more intuitive than for in commands. I never been able to get my mind around for in bat commands longer than an hour before i forgot the twisted logic.

You can echo the Y to the command line, and you can also get cacls to apply the permissions recursively using the /T switch (don't need to do a loop or anything) - like this:


Make sure you change the folder this applies to (currently J:\Shared) and check the switches are correct for the permissions you want! The above is just an example! Run "cacls /?" to see all the switch options, etc.

Once you can see that it is working, change the /k to /c and add ,,Hide to the end of the RunWait command (after F) like so:



I personally don't like giving the "Everyone" or "Users" group Full Control of any shared folders on my machine, but see what works for you. Try changing the F at the end of the command to R and that should still give you the ability to listen to the files.

I will have to explore this further to see if I can limit kids to certain folders and wife to others.

On one hand, cacls is better than filecopy/filedelete if you have a few hundred megs to move, since it is less harddrive churn. But then, you have user specific permissions, a preference of each user.

I still am doubtful the error is solely a windows responsibility. This, since move with dos doesn't do the problem. Neither cut in paste in explorer.

I am hoping a work-around will be built into the code of next ahk, so a permission doesn't cause file read failure.

I got this to work, but wonder if I can improve so a permission can be read from then same permission can be applied to everything else.:

OK, it took me a while to get this working (I am not exactly an expert in DllCall) but I have it tested and working for me this end.

Forget about CACLS - the below script will MOVE the files/folders you specify and ALWAYS INHERIT the permissions from the destination directory (i.e. sets the security attributes as empty, forcing inheritance), which I believe should solve your problem. It is the "FOF_NOCOPYSECURITYATTRIBS" option that bypasses normal rules and doesn't move the security attributes over with the file (acts like the file/folder was copied).

The below should be able to move the files for you, and avoid the need for any manual changing of permissions or using CALCS or anything else (hopefully).

Change the FromDir and ToDir variables to suit.



Please can someone more experienced correct me if I have done something bad in setting up this DllCall? There may be AHK scripts that do this already (but it was fun for me trying to get this to work), but if not, shall I 'functionise' it?