Use either the active or passive mode to connect to a File Transfer Protocol (FTP) server.
Active mode vs. passive mode
FTP utilizes two ports, a data port and a command port, to transfer information from a client to a server. Typically, the command port uses port 21 and the data port uses port 20. When you use a different mode, however, the data port does not always use port 20.
In active mode, the FTP server responds to the connection attempt and returns a connection request from a different port to the FTP client. Network Address Translation (NAT) configurations block this connection request.
In passive mode, the FTP client initiates both connection attempts. NAT configurations do not block this connection request.
If FTP users exist on the private network side of a NAT configuration, you must enable FTP’s passive mode and open the passive port range in your FTP server’s configuration file. You may also need to open the passive port range on your firewall.
IF ERRORLEVEL is a special syntax supported since the DOS days, the %ERRORLEVEL% variable support was added in WinNT.
The original syntax is used like this:
call someapp.exe if errorlevel 1 goto handleerror1orhigher if errorlevel 0 echo succuess...
To use the variable, use the normal IF syntax:
if %errorlevel%==0 echo success...
Note that %errorlevel% stops working if someone does
set errorlevel=foo and it might not get updated for internal cmd.exe commands.
An alternative solution is to use &&:
call someapp.exe && (echo success) || (echo error!)
These days, we are monitoring this issue:
when one was developing a utility that monitors log files as they are updated.
On 2003, opening the log file folder in explorer, you can see the timestamp and files size change before your eyes each time the log is updated.
On 2008, “Last Modified” field on log files is not updated unless another program attempts to open the file or the utility is stopped, even if F5 is pressed to refresh the view.
Explorer gets is information from NTFS, by using a cmd prompt and “dir” we found that the NTFS metadata for the files is not updated until the handle to a file is closed.
Refreshing the information of a FOLDER is just going to go to the (memory resident) metadata cached by NTFS, but querying the file explicitly will force disk I/O to get the properties – this was a design change introduced in Vista to reduce unnecessary disk I/O to improve performance
There are some exceptions to this rule:
– in some, but not all, cases a simple “dir filename” is enough to refresh the metadata
– “special” folders may be treated differently, such as user profiles where we do not expect a large number of files and want to be able to rely on the file data presented
– kernel filter drivers may change the behaviour as by design they “add, remove or
change functionality of other drivers”
As the workaround is for any process to open and close a handle to the log files, a tool was written to do exactly that, plus get the file information, using the following APIs:
Every process has an environment block that contains a set of environment variables and their values. There are two types of environment variables: user environment variables (set for each user) and system environment variables (set for everyone).
By default, a child process inherits the environment variables of its parent process. Programs started by the command processor inherit the command processor’s environment variables. To specify a different environment for a child process, create a new environment block and pass a pointer to it as a parameter to the CreateProcess function.
In this article we explained that in a 64-bit Windows the System32 folder is intended for 64-bit binary files (DLL files etc.) and the SysWOW64 folder is intended for 32-bit binary files. In the article we also explained that if a 32-bit application includes the “\System32” folder name in a folder path, the system automatically makes a redirection to the SysWOW64 folder. This is to prevent compatibility problems when applications are compiled to 64-bit executables.
Timothy Warner, author of Sams Teach Yourself Windows PowerShell in 24 Hours, differentiates between the often-confused terms WMI and CIM, and explains how best to use these technologies with Windows PowerShell.
Let’s imagine that you and I started a business manufacturing and selling network interface cards (NICs). Industry standards would be pretty important to us, right? How could we make it easier for our Ethernet NICs to work natively with systems based on, say, Windows, Linux, and OS X? What about compatibility with different network architectures, protocols, and client/server applications? (Whoa-I’m glad we don’t really need to worry about that particular set of problems!)
Continue reading “Efficient Windows PowerShell Administration with WMI and CIM”
It’s not unusual to see folks write PowerShell scripts and functions whose first line is [CmdletBinding()]. What’s it do?
It’s generally a big part of advanced functions, or what some folks call “script cmdlets.” Basically, it turns on cmdlet-style parameter binding capabilities, either for a script or for a function. You really get four magical capabilities with it:
- The ability to add [Parameter()] decorators to parameters – see “about_functions_advanced_parameters” in PowerShell for more detail. Technically, these can be used without adding [CmdletBinding()], but you almost always see them together.
- The ability to use Write-Verbose and Write-Debug in your script or function, and have their output controlled by -Verbose and -Debug parameters of that script or function. You don’t need to declare those parameters – [CmdletBinding()] adds them.
- Your script or function picks up the other common parameters, too, like -EV and -EA (see “about_common_parameters”)
- The ability to have -whatif and -confirm added to your script or function, by specifying something like [CmdletBinding(SupportsShouldProcess=$True,ConfirmImpact=Medium)]. You still have to implement support for these switches by using $pscmdlet.ShouldProcess() in your script.
If you are using PowerShell v3, you can use the
The “blocking” part is simply an alternate data stream of the file, named “Zone.Identifier”. You can display it in CMD by using input redirection (no other way to get to a stream in CMD, though):
H:\Downloads> more < test.exe:Zone.Identifier [ZoneTransfer] ZoneId=3
You can find them using
dir /r on Windows Vista and later:
2009-10-24 12:18 54.538.056 test.exe 24 test.exe:Zone.Identifier:$DATA
Also in CMD you can easily get rid of that by overwriting it (using output redirection, this time):
which isn’t quite the same as removing the ADS completely, but works in that Explorer doesn’t complain anymore.
There doesn’t seem to be native support for handling ADS from within PowerShell (as mentioned on The PowerShell Guy’s blog here. That article also has some information how to get that functionality in PowerShell). You could, however, simply call cmd:
cmd /c "echo.>test.exe:Zone.Identifier"
That works from PowerShell as well.
Another option would be Mark Russinovich’s
streams utility which allows you to inspect a file’s ADS and also to delete them. So
streams -d myDownloadedFile.exe
does work as well.