Hi All,
I have a DOS batch script file that is scheduled to run hourly, to move any PDF files from a bunch of folders, and put them in one folder. When I view the target folder in Windows Explorer, all of the PDF files have a padlock icon on and are not visible over on the workgroup share.

The source folders are shared Dropbox folders (don't know if that makes a difference?). The target folder is on a local drive, but is shared across a workgroup, and the PDF's do not show up on other computers unless the padlock icon is removed. I eventually found that if I change the permissions to add user 'everyone' the padlock icon disappears and the files are visible again, although there are other PDF files in the target folder that have come from a different source, and these don't have the 'everyone' user set, but still show up correctly. If I drag and drop the files using Windows Explorer the same problem arises.

The batch consists of multiple 'move' commands:
move "c:\users\owner\Dropbox\User1\*.pdf" "c:\shares\IncomingPDFs\"
move "c:\users\owner\Dropbox\User2\*.pdf" "c:\shares\IncomingPDFs\"

So... is the batch file the best way of collecting all the PDFs into one folder? Is the 'permissions' thing the actual problem, or does this just get round it?
I could use copy or xcopy but then I would then need to delete the original files so wildcards are out in case the users have added any files between the processing of the copy command and the delete command. Can DOS handle 'for each PDF file in folder...'?

Any suggestins welcome.
toomutch

Dani AI

Generated

Short summary for (and following up on and ): the padlock and the visibility problem happen because the moved files keep the original NTFS ACLs when you move them inside the same NTFS volume, so files that were created in a private user folder remain private after a plain rename/move. Explorer’s padlock overlay means the item is “private” (only one account / no group ACEs), so other workgroup users don’t see it. (scribd.com)

Why some PDFs in the destination look fine and others don’t: files that were copied into the folder (or created there) inherited the destination folder’s ACLs, while files that were moved/renamed from a different folder kept their original, more restrictive ACLs. That explains why dragging (a same-volume move) shows the same problem as your batch move commands. (scribd.com)

Practical, low-risk fixes and a recommended workflow for an hourly job:

  • Use Robocopy so the files are copied (created in the destination and therefore inherit destination ACLs) and then deleted from source with one step. Test with the list-only /L switch first.
  • If files have already been moved, use icacls to reset them to inherit the folder ACLs.

Example (test with /L first):

robocopy "C:\Users\owner\Dropbox\User1" "C:\shares\IncomingPDFs" *.pdf /L

When happy, run:

robocopy "C:\Users\owner\Dropbox\User1" "C:\shares\IncomingPDFs" *.pdf /MOV /R:1 /W:1 /LOG:C:\Logs\move_User1.log

Then (if needed) force destination files to adopt the folder’s inherited ACLs:

icacls "C:\shares\IncomingPDFs" /reset /T /C

Robocopy’s default copy flags do not copy NTFS security (so new files inherit destination permissions); /MOV deletes source files after successful copy. icacls /reset replaces file ACLs with the default inherited ACLs for the matching files (use /T /C for recursion and to continue on errors). Always test on a small set and back up ACLs first (icacls has /save and /restore). (learn.microsoft.com)

Quick troubleshooting checklist: inspect the Security tab and Ownership of an affected PDF (explicit ACEs vs inherited), run the robocopy /L dry run, and if you must change many existing files, export ACLs and then use icacls /reset or enable inheritance on the target folder and apply (“Replace child object permissions…”) from the folder’s Advanced Security UI.

Recommended Answers

All 3 Replies

Did you check out this page?
http://support.microsoft.com/kb/310316

Contains (seems useful for you):
"By default, an object inherits permissions from its parent object, either at the time of creation or when it is copied or moved to its parent folder. The only exception to this rule occurs when you move an object to a different folder on the same volume. In this case, the original permissions are retained."

It looks so compilcated.

DOS can handle 'for each PDF file in folder...' but it is a bit messy. You could do something like this:

@echo off

REM: 'for each PDF file in folder...' demo by SalmiSoft
REM: Copies all PDFs from a number of source directories to
REM: a common target directory.
REM: Files that are successfully copied to the target directory
REM: are deleted from the source directory

setlocal
for %%F in ("c:\users\owner\Dropbox\User1\*.pdf") do call:MOVEPDF %%F
for %%F in ("c:\users\owner\Dropbox\User2\*.pdf") do call:MOVEPDF %%F
endlocal
goto:EOF



:MOVEPDF
  set newfile="c:\shares\IncomingPDFs\%~n1.pdf"
  echo Moving %1 to %newfile%...
  copy %1 "%newfile%"
  if exist %newfile% del %1
goto:EOF

You will want to add more error checking, but this should get you started.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.