I had a bug in a script where I'd specified -Description $dest instead of -Destination $dest on a call to Start-BitsTransfer.
It didn't error / ran quickly for a small file and took a while for a large one.
As such I think the file was copied to my machine; I just can't find where it was copied to...
Question
Why isn't Destination a mandatory field?
Where do files go by default / when Destination isn't specified?
The snarky answer to the first part of your question would probably be "because Microsoft said so". Since I wasn't involved in the decision making I can't give you a definitive answer, but example 7 of the cmdlet documentation mentions that
The destination path cannot use wildcard characters. The destination path supports only a relative directory, a rooted path, or an implicit directory (the current directory).
So I would suspect that the parameter was made optional to allow transferring files "here" (to the current working directory) without having to explicitly specify a destination, i.e. for simplicity of use.
Related
I am trying to get all the Children of my File.
When I run the following piece of code:
#taking the input of the user!
$pathInputByUser= Read-Host ("Please Enter the Path!")
#Entering the path entered by the user
cd $pathInputByUser
#getting all the files and folders from our path
$AllFilesAndFolders= ( Get-ChildItem -Recurse -File );
A few minutes after I run this code, I get the error described in the title:
"A part of the path could not be found" even though it obviously exists.
How can I solve this problem so that I can get all the children?
Guess 1 :
One of the answers in this stack overflow links suggests that the name of the path is simply too large for windows since windows has some limit of 260 character.
to solve this
one can simply change the names of the folders [not possible in my case since the file
structure belongs to another company]
The "\?" prefix can be perhaps appended before the path and then it could work [didnt work in my case, my path starts with "//" already perhaps thats why it doesnt work.
Anywho, the person had linked a microsoft documentation and perhaps you guys might understand something more than me.
Any help would be appreciated!
Given this (real) Registry path...
HKEY_CLASSES_ROOT\Local Settings\MrtCache\C:%5CProgram Files%5CWindowsApps%5C89006A2E.AutodeskSketchBook_1.6.0.0_x64__tf1gferkr813w%5Cresources.pri\1d3438f5876f755\6dfb7f2f\#{89006A2E.AutodeskSketchBook_1.6.0.0_x64__tf1gferkr813w?ms-resource://89006A2E.AutodeskSketchBook/Files/Assets/AppLogo/Orion_Tiny.png}
where the property name is...
#{Microsoft.Office.OneNote_17.8625.20901.0_x64__8wekyb3d8bbwe?ms-resource://Microsoft.Office.OneNote/Files/images/OneNoteAppList.png}
I am trying to figure out how to properly deal with extracting the data value. I need to differentiate the path to the containing key from the property name, but because the property name contains / and Split-Path converts those to \ and treats them as key delimiters, I get bad data out of that Cmdlet. From a programming standpoint the solution is to not start with a single path. However, I am somewhat constrained by existing data in XML files that provides only a single path. For 99.9% of cases, including drive and UNC file & folder paths, registry Key & Property paths as well as URL paths, Split-Path works. But for this very specific situation it fails. Is there a .NET solution that can be depended on? Or is this a case where there is no solution other than to break up the data and curse Microsoft for their inconsistency and incomplete solutions?
I get that this example is probably a situation I will never actually run into, but I have been burned before with things like assuming anything with an extension is a file and then finding someone (usually Autodesk) has decided to name a bunch of folders with a . in the name, causing code with that assumption about naming conventions to fail. So I am looking for a consistent way to deal with this, if one exists. Ideally in PS 5.1, not PS Core, as I cannot and will not demand that all my users upgrade to a new version of PowerShell to address such an edge case.
EDIT: I should also mention that a similar issue arrises when there is a / in a key name, and I want to verify that the key exists. HKLM\Software\Key/Name is a perfectly valid path, and Split-Path will soil itself every time and come back with Name as the leaf, not Key/Name. Because Split-Path doesn't actually understand what's valid as a registry key name, it seems.
I am moving CIFS share files and subfolders from one system to another, and I want to set the top level folder at the destination to have same ACLs as the top level folder at the source. In some cases this is up to 25 users and groups.
Is there a way to get the ACLs from the source top level folder, and pipe that output so it is applied to the top level destination folder?
You can copy an ACL very easily:
Get-Acl -Path <SourceFolder> | Set-Acl -Path <DestinationFolder>
But this isn't very eloquent. It will only take the ACL from one folder and apply it to another. Given you are going to copy a whole tree your milage may vary.
Robocopy is often used in these situations with the /COPYALL parameter. You can create the tree without copying with /CREATE. You may have to tinker around to get it to do only one folder. Hard to say without knowing the particulars of your project, but if you're interested check the help file.
I'd also point out, there is an awesome NTFS module here. I use it all the time it's very capable, and very easy to script around.
Let me know if this is helpful.
I'm looking for solution to delete or (preferably directly) overwrite source of an exe file while it is running.
To explain further before you get it all wrong, I'll give an example:
I have an exe file on drive D:\ which I run (with previously posted question's answer, giving params to "Start in" folder on C:\Program Files\MyProgram\" so it finds its dlls.
Now after the file is running, I'd like to rewrite the file's byte stream (just like opening it in hex editor...), or at least delete it so I can copy over new exe file directly using same name.
So far the solution I'm using is that I trigger format D: command for the whole drive D:\ (which, in my case is ramdisk and thumb-drive, as I only have this exe on it, I copy it there as necessary), since that removes the file and let's me copy new file there.
Trying to use del myProgram.exe even with -force flag triggers error that access to the file is denied. Same goes if I try to overwrite the contents of the file.
Is there any alternative to do that without using the format command, as that requires to have partition drive only for the purpose?
Update: Note: MoveFileEx and similar techniques that require termination of the process or system restart/reboot are not qualified as a solution. This should be done while the process is running without further actions that can compromise the process's run state.
On a side note, when formatting the drive using the Powershell's format command, the file is gone, although if viewing the partition using Hex viewer tool, there is full binary (hex) content of the exe visible there and an be restored using just as simple as copy-paste technique. This is one of the points as to where overwriting the file contents would be preferable than deleting the file directly.
Please note: This is a knowledge and skills based question, and would therefore appreciate sparing the moral and security-concerning comments about such actions and behaviour.
For deleting/replacing/overwriting a file at least two conditions must be met:
The user performing the operation must have the required permissions to do so. This can be verified for instance via Get-Acl or icacls.
Windows must not have an open handle to the file. This can be checked for instance with tools like Process Explorer or handle. These tools can also be used to forcibly close open handles, although that's not recommended as it may cause data loss and/or damage to the files in question. I'm not sure, though, if it's actually possible to close handles to an executable without terminating the process.
Note that antivirus software is likely to interfere with this kind of operation.
The basic problem here is that Windows loads from the .EXE upon demand, it's not all read in at once.
If you destroy the original file what happens when it tries to load in a page that no longer exists?
If I had to write something of this sort I would copy the .exe to a temporary location (beware that running code from the temp directory may be prohibited), run the new .exe, terminate the old one and then do what I want to it.
I have an executable in a directory that is versioned, so the directory changes when the tool is updated.
The current command I run is the following:
.\packages\Chutzpah.4.1.0\tools\chutzpah.console.exe .\Tests\chutzpah.json
I want to do something like the following:
.\packages\Chutzpah**\tools\chutzpah.console.exe .\Tests\chutzpah.json
Windows command line doesn't like to expand wildcards but I'm hoping this is possible with powershell.
Simple answer here could be to use resolve-path which
Resolves the wildcard characters in a path, and displays the path contents.
So in practice you should be able to do something like this.
$path = Resolve-Path ".\packages\Chutzpah**\tools\chutzpah.console.exe" -Relative
& $path ".\Tests\chutzpah.json"
Note that Resolve-Path has the potential to match more that one thing.
Actually, Windows will expand the wild cards, but if the non-wildcard portion is not unique, you'll get the (I think) FIRST match.
So I think that really your problem is
"How do I tell which version I should be executing"
Which, if you have project files, etc., you might be able to extract from there.
In fact, you might well be wanting to extract something from the solution packages.config file, assuming that the .\packages\ prefix is there because you are wanting to run tests against files that are in a NuGet package.
Can you supply some more details?
EDIT:
OK, so you probably need to do something like System.IO.Directory.GetDirectories(path, pattern)
https://msdn.microsoft.com/en-us/library/6ff71z1w(v=vs.110).aspx
And depending on what you'd done with "Chutzpah" you'll get one or more matches that you could use to select the correct path.