In all these things, you always have to specify the full filename incl. extension; it's just that you have "chosen" to hide usual extensions in Explorer only for display purposes. You can see the extensions by doing "DIR" in the Command window.

I thought that it was files on Win7 E:\ that don't cause trouble on XP. What does one of their CACLS look like?

I'd wish you'd do the "CD folder" before doing the "CACLS simple-file-name-without-the path"; it's much clearer to see the output on the left of display, e.g.

CD \Users\you\Videos
CACLS "Redwing 13-01-10.m2ts"

Are you still having Read Only permissions issues on XP with files transferred from Win7 C:\? In testing this you should 1st delete any previous XP copy in case your previous massaging of permissions on XP affects it.

XRaySpeX,

I really appreciate your help with this

I always hide file extensions in case I rename a few files and forget to add or leave them in place because later I may not remember what the hell a file is - especially true with the myriad of video file extensions...

I discovered that I needed extensions when I did this: ICACLS C:\Users\me\Videos\* and all the file names came up with extensions.

Will do the tests that you requested later, and I WILL "CD folder" first.

Off out to do some filming now, speak to you later,

4M2.

XRaySpeX,

http://farm7.static.flickr.com/6089/6042658727_68156... - I used both cacls and ICACLS for a video on the Win7 E:\ drive.

Also deleted the previously troublesome "clearcloud.mp4" file from the XP Shared Documents folder and copied it again across the network from the Win7 C:\...\Videos folder to the XP Shared Documents folder using the Win7 machine - which is my normal procedure. Now no problems working with that file using XP

Having a few problems with cd and cacls commands but that obviously didn't matter with the Win7 E:\ drive.

Looks like the the problem has gone away ... for now as I can't see that you have changed anything that would affect new files transferred from Win7 C:\ to XP.

The permissions of that file on Win7 E:\ looks perfectly normal.

I suspect the issue stems from the presence of those permissions for "WMPNetwokSvc" (which I've never seen before but I don't have Win7) amd the "Accounts not found". What happens if you just manually create an arbitrary text file (using Notepad) in C:\Users\you\Videos? What ACLs does it end up with?

How differently were the files on C:\ and E:\ originally created?

PS: No need to use ICACLS; I am more familiar with CACLS and they both do the same thing.
I forgot to say before doing a CD on E: you need to switch drive by just issuing "E:" alone, as you did.

XRaySpeX,

http://farm7.static.flickr.com/6080/6044123966_ba680... - new text file, as you can see I'm still having problems getting the cd and cacls commands to produce an easily readable display in Win7 Command Prompt

Regarding those "Accounts not found" I haven't mentioned this before, in order not to complicate the issue, but when I first connected up the Win7 machine to the LAN a couple of years ago I used the WORKGROUP setup. And much to my dismay I was able to read the entire Win7 C:\ drive from the XP machine, so I used this fix: http://scottiestech.info/2009/09/25/windows-7-file-s... It is perhaps possible that procedure has something to do with "Accounts not found"?

The video files on the Win7 C:\ and E:\ drives were all created by the Sony Vegas editor and exported using the H.264 AVC codec with only minor changes to parameters.

Looks like those funny ACLs happen to any file in that folder. They must be inherited down the line. Wonder what the ACLs are of the Videos folder itself and so on up the line until C:\.

That article looks perfectly reasonable. I doubt it would have caused those funny ACLs but it does say that file sharing was changed in Win7, so I guess it is Win7 itself that has produced them. As I said above, I wonder how far up they exist.

Other than that, I think we have gone as far as we can go on this. If XP permissions issues occur again you will just have to massage them as before. Or you can try deleting the funny ACLs on a test file in Win7 C:\ before transferring to XP.

PS: Forget what I said about having to do a CD 1st; it does not really help.
You know you can Mark & Copy from the Command Window by right-clicking on it?

In reply to a post by 4M2:

Booting into safe mode did the trick: had to check "Full Control" from Security.

To which file or folder did you do this? And for which user/group?

If you did it to a folder it will explain why you no longer have problems with new files transferred to that folder.

XRaySpeX,

http://farm7.static.flickr.com/6078/6045780044_f45d6... - XP Command Prompt showing the current status of one of the previously troublesome files, that I deleted and copied across again, and also of the Shared Documents folder.

Yes in XP safe mode I checked "Full Control" for the Shared Documents folder, i.e. C:\Documents and Settings\All Users\Documents.

Will have a play around with the funny ACLs on a test file in Win7 C:\ etc. etc. later...

Thanks for the tip regarding Mark &Copy from the Command Prompt window should make things easier by pasting the text into Notepad

Virtual Dub app counts as some form of media player, i.e. it is actually decoding the frames help with in the file.

MrSaffron,

Apologies, you are indeed correct that VirtualDub decodes a supported codec when a file is opened for processing or playback, and it that sense it is certainly a media player.

Problems can occur however for some supported codecs when they are not licensed for a particular process using certain filters/plugins and then the display windows will fail and the processing will also fail. That, as you suggest, is a processing\encoding issue rather than a decoding issue....

4M2.