I have a batch file that I use (and have used all day successfully) to copy some badly named files (all are 1.csv) in a horrendously long dir tree to a different location with a more appropriate name (and shorter route to the file). It suddenly quit working; specifically, it IS making the new directory and it IS making the file with the correct name; however, the 'new' file is basically void. The source file may be 26mb but the destination file created is 287k. I'm using
xcopy "Z:\jobs\!q-z\clientname\tars\2016_06_06\home\abcd\xyz\qwert\more\moarr\deeper\deepest\x\y\z\1.csv" "Z:\jobs\!q-z\clientname\daily\160606\biz.csv*"
As I said earlier, this was working just fine all day long and suddenly began creating all dest files exactly the same size, which is an empty shell of a csv file. I have a feeling this might have to do with some sort of "cache" issue, but if so, I don't know how to clear it. Or is there some error in my syntax that allowed it to work almost accidentally before today? I've tried using pretty much every switch for xcopy, with no better results.
Also, the only thing that ever changes in the batch file is the date.
Related
Im not scripting alot so i think this is total beginner stuff so
i have following problem, i want to move (like cut-out and paste) a folder ,that always starts with the same string but never have the same ending, to another folder.
Im working on a Windows Server that runs a Batch. The Batch is copying different Backup-Files to a Directory with a timestamp. This works fine because all the other Files and diretorys that i need to move have static names.
But im running into a problem with a folder/directory that has a dynamic name. The Folder starts always with the GUID {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx} of the Application, so the start fo the directory name is static. But at the end, the Application is adding a underline _ followed by random charaters so the directory looks like following f.E. :
{11111111-1111-1111-1111-11111111111}_ehgwuh238th
This is how my other files with the static names are handled so far:
if exist %path%\%fullstamp% move %path%\Test %path%\%fullstamp%
path contains the path to the directory that includes the files that need to be moved.
fullstamp contains a timestamp which were used to create a new directory at the beginning of the batch.
I tried something like:
move %path%\Test* %path%\%fullstamp%
move %path%\Test*. %path%\%fullstamp%
move %path%\Test*\ %path%\%fullstamp%
But none of these worked out
So like i said probably not a big deal but i still need to ask.
To summarize it:
the directory that always starts/contains with the same string need to be moved to another directoy.
Some directoy names f.E.
Test_31tß0t30
Test_3tggwqgrgwrg
Test_ksmrh82ra
Thank you in advance and sorry for my bad english.
The move command seems to not accept wildcards for source directories, so you will need a for /D loop to resolve the path first:
for /D %%I in ("%ROOT%\Test*") do move "%%~I" "%ROOT%\%fullstamp%"
I also quoted both source and destination paths in order to avoid trouble with whitespaces or other special characters.
The fact that you use a variable %path% makes me think you set it to the root path of your operation, but PATH is a reserved variable used by the system to find executables, so you should not (over-)write it. That is why I used another variable name ROOT in my code suggestion.
Every week at work, I am responsible for manually moving 100-200 files from one folder into a corresponding subfolder. After doing this for a couple of weeks, I thought to myself: This can be done faster!
I have used Python 2.7 and 3.X a bit at school, but mostly with (very) basic search engines and text search.
I found another thread, where a guy was told to use either os.rename or shutil.move. I made a simple test with os.rename:
os.rename("path/to/current/file.foo", "path/to/new/desination/for/file.foo")
And it works, so far so good.
Is there any way to make python run through every file from a folder and move it into a corresponding subdirectory in another folder? The original directory contains all the files, while the target directory contains all the folders.
Every file (A_file, B_file, etc.) has the same name as the folder(A_folder, B_folder, etc), which means they are in the correct order.
This makes me think a simple iteration could work, as in(More of an algorithm than code):
for file in original_dir
move file to folder_x in tar_dir
x += 1
Obviously this is not complete, but maybe someone can point me in the right direction.
This makes directories recursively.
os.makedirs(path)
So you pass the path to the directory you want. eg /path/to/
Which you would follow up with the copy.
def move_file(new_path_to_file, file_to_move):
file_name = file_to_move.split(os.path.sep)[-1]
os.makedirs(new_path_to_file)
os.rename(file_to_move, os.path.join(new_path_to_file, file_name))
You could also make it easier by passing in the filename as well.
Trying this I have found a strange problem:
Delete an old file.
Create a new file and name it the same as the old file.
Then the "created time" property of the new file is set to the "created time" of the old file. Why does that happen? And how?
It's due to file system tunnelling, as explained by Raymond Chen:
"Why does tunneling exist at all?
When you use a program to edit an existing file, then save it, you expect the original creation timestamp to be preserved, since you're editing a file, not creating a new one. But internally, many programs save a file by performing a combination of save, delete, and rename operations (such as the ones listed in the linked article), and without tunneling, the creation time of the file would seem to change even though from the end user's point of view, no file got created.
As another example of the importance of tunneling, consider that file "File with long name.txt", whose short name is say "FILEWI~1.TXT". You load this file into a program that is not long-filename-aware and save it. It deletes the old "FILEWI~1.TXT" and creates a new one with the same name. Without tunnelling, the associated long name of the file would be lost. Instead of a friendly long name, the file name got corrupted into this thing with squiggly marks. Not good."
The NT file system does not delete a file when you think it does. When you delete a file on an NT file system the operating system simply marks the disk space that file occupied as available. The file will not be truly deleted until another file is written to that location on disk.
As to why Windows would think it was the same exact file I believe this is due to the fact that the file was empty when you deleted it so creating a new file in the same location with the same name and the same (empty) contents makes Windows think it is in fact the same file. I would consider this to be a bug.
As a side note, the fact that Windows handles file deletes in this way is the very reason that you are able to use file-recovery utilities to recover deleted files.
You can update creation time with this command manually:
powershell (ls YourFile.txt).CreationTime = Get-Date
... and the same in a batch file:
call powershell "(ls YourFile.txt).CreationTime = Get-Date"
I need to quickly write a simple GUI over a command line application. Two steps are required:
Specify an input file path,
Specify an output file path (non existing)
I found out a previous post, however trying to get the above (1) to work seems like an insane task.
Indeed BrowseForFolder seems to only work in some weird cases, you can use BIF_BROWSEINCLUDEFILES for only *.pdf and/or *.txt (trial and errors). I can get an error if I select a *.dll and/or a *.jpg (don't ask).
So instead, I gave up this approach and followed another one, in this case (objIE.Document.all.FileSelect), only the name of the selected file is returned the path seems to be always set to "c:/fakepath" for some reason. So again I am missing the full path to be able to pass that to the command line app.
Is there any sane way (<10 lines of codes) to get (1) and (2) working on Win7/64bits (VBS, HTA...)?
Don't know if people are still interested in the BrowseForFolder file selection issue, but here's what I've found.
I had the same issue selecting files with BrowseForFolder using &H4000 / BIF_BROWSEINCLUDEFILES. I could get a return with .docx but not .doc files and as you say .pdf files.
For me .txt wouldn't return anything, as didn't WMI Backup .rec files that I needed for a script I'm writing, resulting in this error information:-
Error: Unspecified error
Code: 80004005
Source: (null)
After looking at other solutions I came back to this one as my preferred choice, plus it was doing my head in that it didn't want to work. So at the bitter end it seems to be this easy.
To get my .rec files recognized I add this to the registry:-
[HKEY_CLASSES_ROOT\.rec]
#="WMI.Backup"
[HKEY_CLASSES_ROOT\WMI.Backup]
#="WMI Backup"
"BrowseInPlace"="1"
To get .txt files recognized I add this to the registry:-
[HKEY_CLASSES_ROOT\txtfile]
"BrowseInPlace"="1"
So "BrowseInPlace"="1" seems to be the nugget.
Seems so unbelievably easy that I'm sure this solution is out there somewhere but I never came across it so thought I'd put it online.
I would be interested to find that it works for others as I fear that this issue may of sent me mad, still can't believe it seems to work.
Hope this helps.
Here are 3 different ways to do what you want:
http://www.robvanderwoude.com/vbstech_ui_fileopen.php
Trying this I have found a strange problem:
Delete an old file.
Create a new file and name it the same as the old file.
Then the "created time" property of the new file is set to the "created time" of the old file. Why does that happen? And how?
It's due to file system tunnelling, as explained by Raymond Chen:
"Why does tunneling exist at all?
When you use a program to edit an existing file, then save it, you expect the original creation timestamp to be preserved, since you're editing a file, not creating a new one. But internally, many programs save a file by performing a combination of save, delete, and rename operations (such as the ones listed in the linked article), and without tunneling, the creation time of the file would seem to change even though from the end user's point of view, no file got created.
As another example of the importance of tunneling, consider that file "File with long name.txt", whose short name is say "FILEWI~1.TXT". You load this file into a program that is not long-filename-aware and save it. It deletes the old "FILEWI~1.TXT" and creates a new one with the same name. Without tunnelling, the associated long name of the file would be lost. Instead of a friendly long name, the file name got corrupted into this thing with squiggly marks. Not good."
The NT file system does not delete a file when you think it does. When you delete a file on an NT file system the operating system simply marks the disk space that file occupied as available. The file will not be truly deleted until another file is written to that location on disk.
As to why Windows would think it was the same exact file I believe this is due to the fact that the file was empty when you deleted it so creating a new file in the same location with the same name and the same (empty) contents makes Windows think it is in fact the same file. I would consider this to be a bug.
As a side note, the fact that Windows handles file deletes in this way is the very reason that you are able to use file-recovery utilities to recover deleted files.
You can update creation time with this command manually:
powershell (ls YourFile.txt).CreationTime = Get-Date
... and the same in a batch file:
call powershell "(ls YourFile.txt).CreationTime = Get-Date"