AutoHotkey Community

[degarb]

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. %100 reproducible here.

Windows xp pro, sp3.

[OceanMachine]

We don't believe this to be a bug at the moment, do you agree?

http://www.autohotkey.com/forum/viewtopic.php?t=54323
http://www.autohotkey.com/forum/viewtopic.php?t=52477

[degarb]

Yes, that first link was mine. Found it is most certainly some permission getting corrupted on file move. ( I say corrupted because of cacls stated permissions seem correct, to me; while running the cacls loop can fix the problem.)

I do still feel it is a bug, since wrapper or not, the dos move command does not have this permission problem. Nor a simple cut and paste.

Also, even if it were a bug in windows, there may be a solution that could be implemented. At present, I must churn the hard drive with a filecopy/delete, even if just moving/reorganizing a few gigs. Or there is the cacls method as in that thread. But the downside there, is I don't wish to play with someone elses permission on someone elses machine in a shared compile. Maybe I might get a handle on determining current permissions and applying to all moved files (if you have code, it would save me time.). Still this is a good deal of work for every script.

If some ideal solution (no matter windows fault or ahk) cannot be put in a future release, at least put a link to the situation in the chm.

[OceanMachine]

Well, bug or not, I have a solution that should get round this issue (for some people anyway) via DllCall, hope it helps someone out (its the first post linked above):
http://www.autohotkey.com/forum/viewtopic.php?t=54323