bcl Issue Tracker Rss Feed

Created Issue: LongPathDirectory.Create() [12912]

Andrei15193 — Thu, 09 May 2013 15:35:21 GMT

Hello,

Unlike the System.IO.Directory.CreateDirectory(), the Microsoft.Experimental.LongPathDirectory.Create() does not create a directory structure if it does not exist. For instance if I am in a folder with no subfolders, a call to LongPathDirectory.Create("A\\B"); will fail while a call to Directory.CreateDirectory("A\\B"); will not fail and create the A subdirectory and then the B subdirectory in A.

Yours,
Andrei

Created Issue: TraceEvent GetProviderName NullReferenceException [12872]

LTruijens — Mon, 01 Apr 2013 20:30:34 GMT

Calling TraceEventSession.GetProviderName always results in a NullReferenceException. That is because the getter of the ProviderGuidToName property fails to create the dictionary before filling it.

private static Dictionary<Guid, string> ProviderGuidToName
{
get
{
if (s_providerNames == null)
{
foreach (var keyValue in ProviderNameToGuid)
s_providerNames[keyValue.Value] = keyValue.Key; // NullReferenceException
}
return s_providerNames;
}
}

The fix is simple. Create the dictionary before the foreach

private static Dictionary<Guid, string> ProviderGuidToName
{
get
{
if (s_providerNames == null)
{
s_providerNames = new Dictionary<Guid, string>(); // FIX
foreach (var keyValue in ProviderNameToGuid)
s_providerNames[keyValue.Value] = keyValue.Key;
}
return s_providerNames;
}
}

Created Issue: How to parse a BigRational from a string? [12859]

_ericBG — Fri, 15 Mar 2013 22:35:20 GMT

I'm the situation where I need to parse a BigRational from a string. Is there any way to do this, or would I have to roll my own method?

Commented Issue: ProcessTraceData cannot parse ETL files generated on Windows 8 [12552]

bobuva — Tue, 26 Feb 2013 18:57:53 GMT

Windows 8 generates ETL files that where the MOF class version for ProcessTraceData is 4. TraceEvent does not know how to parse this. There's an unknown 4 byte long field between the DirectoryTableBase and UserSID properties. Unfortunately, this throws off parsing of subsequent fields (like image name) too.
Comments: ** Comment from web user: bobuva **

I've downloaded the TraceEvent.zip that was put up here (on Nov 13, 2012 according to the message info), rebuilt my test program which loads an .etl file, and I continue to get the "Not a understood file format" error thrown from the FastSerialization.Deserializer constructor. All I'm doing is creating a new instance of the Diagnostics.Tracing.TraceLog class in the TraceEvent library.

I've tried it with etl files created from the WPR (recorder) and from PerView, with no luck. Is it possible I'm running into a different problem than the Windows 8 issue mentioned in this thread?

Thanks,
Bob

Commented Issue: ProcessTraceData cannot parse ETL files generated on Windows 8 [12552]

szilvaa — Tue, 13 Nov 2012 16:49:15 GMT

Thank you! I'm hoping that the changes can be propagated soon. I have a few of my own modifications inside traceevent.dll that I'd like to continue to use.

Commented Issue: ProcessTraceData cannot parse ETL files generated on Windows 8 [12552]

vancem — Tue, 13 Nov 2012 14:58:16 GMT

Yes, this has been fixed but it has not been propagated to the codeplex site.

Attached is a updated version of the TraceEvent.dll binary and XML docs that fixes this. it also has significant new features (like RegisteredTraceEventSource),

Created Issue: ProcessTraceData cannot parse ETL files generated on Windows 8 [12552]

szilvaa — Tue, 13 Nov 2012 01:13:07 GMT

Commented Issue: TraceEvent and perfMonitor decode TCPIP events incorrectly. [12458]

vancem — Mon, 10 Sep 2012 17:06:47 GMT

Notice the saddr, TID, and daddr's in the below decoded events by perfMonitor.

<Event MSec= "9371.1619" PID="2896" PName= "chrome" TID= "-1" EventName="TcpIpConnect" size="0" daddr="-1830781622" saddr="-2101342036" dport="20480" sport="23044" mss="1460" sackopt="0" tsopt="0" wsopt="0" rcvwin="64240" rcvwinscale="0" sndwinscale="0" seqnum="0" connid="0x00000000"/>
<Event MSec= "9371.9184" PID="2896" PName= "chrome" TID= "-1" EventName="TcpIpSend" size="687" daddr="-1830781622" saddr="-2101342036" dport="20480" sport="22532" startime="218151" endtime="218151" seqnum="0" connid="0x00000000"/>
<Event MSec= "9583.4596" PID="2896" PName= "chrome" TID= "-1" EventName="TcpIpConnect" size="0" daddr="-1612677814" saddr="-2101342036" dport="20480" sport="23556" mss="1460" sackopt="0" tsopt="0" wsopt="0" rcvwin="64240" rcvwinscale="0" sndwinscale="0" seqnum="0" connid="0x00000000"/>
<Event MSec= "9584.6578" PID="2896" PName= "chrome" TID= "-1" EventName="TcpIpConnect" size="0" daddr="-2065662646" saddr="-2101342036" dport="47873" sport="23812" mss="1460" sackopt="0" tsopt="0" wsopt="0" rcvwin="64240" rcvwinscale="0" sndwinscale="0" seqnum="0" connid="0x00000000"/>

I also created a trace with logman, and then converted with netsh and perfMonitor. perfMonitor was unable to decode the events for some reason?
Comments: ** Comment from web user: vancem **

TraceEvent should work as part of a system service (Frankly most things should).

It is not clear what you mean by 'image mismatch'. If you are on a 32 bit machine, this CAN'T be a 32-64 bit issue (assuming it worked as a console app) since there is no possibilty of confusion.

Thus I suspect you are describing a version mismatch of (maybe the C runtime library?). You can debug these types of things by turning on loader snaps (see http://blogs.msdn.com/b/junfeng/archive/2006/11/20/debugging-loadlibrary-failures.aspx)

Commented Issue: TraceEvent and perfMonitor decode TCPIP events incorrectly. [12458]

fatsailor — Fri, 07 Sep 2012 17:13:06 GMT

No problem on the bug catch. We're planning/hoping to use this extensively so we'll let you know if we find anything else.

BTW - any idea if TraceEvent.dll can be used as part of a system service assembly?

Everything is fine as a console app, but when it is converted to a system service it dies with the dreaded image mismatch on both 64 and 32 bit machines.

We've set all of the build instructions to build a 32 bit assembly, and even tried corflags /32+ and no joy.

Commented Issue: TraceEvent and perfMonitor decode TCPIP events incorrectly. [12458]

vancem — Wed, 05 Sep 2012 15:52:45 GMT

You are correct that port numbers are incorrect. The issue is that the port numbers are in big-endian format (most significant byte first).

I have fixed the current version of TraceEvent.dll however until it is published, you have to work arount it by swapping the upper and lower bytes of the port number (ports are alwasys 2 bytes).

Thanks for uncovering this.

Commented Issue: TraceEvent and perfMonitor decode TCPIP events incorrectly. [12458]

fatsailor — Sat, 01 Sep 2012 13:20:00 GMT

Thanks! I grabbed the new dll, and IP addresses are now printed correctly. However, dest and src ports are still incorrect. The following code:

source.Kernel.TcpIpConnect += delegate(TcpIpConnectTraceData data)
{
Console.WriteLine("PID {0}: TCPIP connect {1}:{2} {3}:{4}", data.ProcessID, data.saddr, data.sport, data.daddr, data.dport);
};

produces this when I open a web page. The dest port is printed as 20480 rather than 80. Thoughts?

PID 3920: TCPIP connect 172.16.192.130:26372 204.160.99.126:20480
PID 3920: TCPIP connect 172.16.192.130:26116 204.160.99.126:20480
PID 3920: TCPIP connect 172.16.192.130:26628 204.160.99.126:20480

Commented Issue: TraceEvent and perfMonitor decode TCPIP events incorrectly. [12458]

vancem — Thu, 30 Aug 2012 15:13:26 GMT

To be clear, the issue is not that the fields of the event are misaligned, simply that the 4 byte integer value is not pretty-printed as a internet address (you simply need to take this value and initialize an IPAddress class with it).

Note that PerfView (at the download site) does have the latest version of TraceEvent inside it right now. Thus if you run that (which auto-installs it) you will find a TraceEvent.dll under AppData\Roaming\PerfView. You can simply use that DLL until the CodePlex site catches up

Commented Issue: TraceEvent and perfMonitor decode TCPIP events incorrectly. [12458]

fatsailor — Wed, 29 Aug 2012 20:58:21 GMT

Thanks - I saw the comment about TCP headers in the code, but wanted to make sure.

Any clues on how to resolve this before the next release is published? I found the classes in KernelTraceEventParser.cs where you unmarshal the event byte stream, but without the MOF file I have no idea what the new order should be short of reverse engineering a few ground truth events.

Also - I'd appreciate if you know of any other Kernel events that have this kind of issue.

thanks for a cool project .....

Commented Issue: TraceEvent and perfMonitor decode TCPIP events incorrectly. [12458]

vancem — Wed, 29 Aug 2012 17:50:13 GMT

This is a known issue. It is fixed but the fix is not published. You can use the PerfView tool (bing it to find the download site). There will be an update to TraceEvent/PerfMonitor in the next month or two.

Created Issue: LongPathDirectory.Create fails when there's a dot in path [12461]

dutop — Wed, 29 Aug 2012 09:26:16 GMT

If I pass a path like "E:\.\asdf", Create( ) fails with an UnauthorizedAcessException. LongPathCommon.NormalizeLongPath( ) changes "E:\." to "\\?\E:\" - the dot is lost. So the native CreateDirectory method tries to create "E:\", of course the drive is already existing. It returns 5, ERROR_ACCESS_DENIED. You would think it should return ERROR_ALREADY_EXISTS, but unfortunatily it doesn't.

If you would pass "E:\\" to LongPathDirectory.Create, an ArgumentException would be fired, what would be ok.

System.IO.Directory.CreateDirectory has no problem with "E:\\.\\asdf", the Windows 7 console (mkdir E:\.\asdf) neither. So I think, LongPathDirectory should handle the . as well.

Created Issue: TraceEvent and perfMonitor decode TCPIP events incorrectly. [12458]

fatsailor — Tue, 28 Aug 2012 11:19:50 GMT

Commented Issue: Add long path FileInfo/DirectoryInfo equivalents [10992]

babzog — Mon, 17 Oct 2011 15:30:23 GMT

Hi there, I'm a noob with c# so my apologies if it's something obvious. First thanks for creating the library it's awesome. I've managed to get all the functions to work as expected but now I need to get the file information that normally WIN32_FIND_DATA
provides when you p/invoke the findfirstfile function. The problem is that I need to analyze about 700k individual files and I don't want to p/invoke findfirstfile because after about 34k calls the my pograms starts to slow down to a crawl. Is there any function
I can use in the library that will give me the equivalent of WIN32_FIND_DATA? If not, I just need the Creation Time, File Size and Last Modiied info. If there is another way to get those using your library it would be greatly appreciated. Thank you for the
great work.
Comments: ** Comment from web user: babzog **

See my post (with patches). [discussion:275022]

Commented Issue: Add more File.* and Directory.* to LongPathFile and LongPathDirectory [7862]

fptmark — Thu, 01 Sep 2011 00:40:41 GMT

It would be helpful to have Long Path versions of all the File.* and Directory.* methods.
Comments: ** Comment from web user: fptmark **

I would like to see GetAttributes implemented

Created Issue: Make LongPathFile and LongPathDirectory behave more like FileInfo and DirectoryInfo [11209]

hightechrider — Mon, 22 Aug 2011 23:48:39 GMT

Suggest:-

1) Change them from static classes to normal classes.

2) Make LongPathDirectory derive from LongPathFile

3) Add these properties to LongPathFile:
public UInt64 Size { get; }
public FileAttributes Attributes { get; }
public DateTime CreationTimeUtc { get; }
public DateTime LastAccessTimeUtc { get; }
public DateTime LastWriteTimeUtc { get; }
public bool Exists { get; }
public string FullName { get; }
public string Name { get; }
public string Extension { get; } }

4) Add methods to get an enumeration of LongFilePath objects from a LongFileDirectory instead of the code you have at the moment that only returns an enumeration of strings. This would be a fairly simple change to the code you already have:-

...
NativeMethods.WIN32_FIND_DATA findData;
using (SafeFindHandle handle = BeginFind(Path.Combine(normalizedPath, normalizedSearchPattern), out findData))
{
if (handle == null)
yield break;
do
{
string currentFileName = findData.cFileName;

if (IsDirectory(findData.dwFileAttributes))
{
if (includeDirectories && !IsCurrentOrParentDirectory(currentFileName))
{
yield return new LongPathDirectory(Path.Combine(pathWithoutPrefix, currentFileName), findData, findData.dwFileAttributes);
}
}
else
{
if (includeFiles)
{
yield return new LongPathFile(Path.Combine(pathWithoutPrefix, currentFileName), findData, findData.dwFileAttributes);
}
}
} while (NativeMethods.FindNextFile(handle, out findData));
...

5) Add the other methods people have been asking for like Delete().

Created Issue: Add TxF support to Long Path [11178]

Kelden — Fri, 12 Aug 2011 23:57:43 GMT

It would be great to have file system transaction support like here http://archive.msdn.microsoft.com/txfmanaged