C# Discussion Boards - CodeProject

15-Apr-09 13:31

Is there a way to stream folder with all subfolders and files in it?
Reason why I am looking for this is to stream folder and save it with my app and later take saved file and restore all subfolders and files with relative path to streamed folder.

harold aptroot15-Apr-09 13:37

15-Apr-09 13:37

You could just zip it together of course SharpZipLib[^]
Also saves some space as a nice bonus.

biggy115-Apr-09 13:51

15-Apr-09 13:51

Thanks for reply,
and yes I am aware of that (sharpziplib, gzip, deflate...) but I need a better performance and just streamed folder.

harold aptroot15-Apr-09 14:01

15-Apr-09 14:01

On minimal compression maybe? Or how about .tar? No compression so there's no way anything else will be faster

biggy115-Apr-09 14:12

15-Apr-09 14:12

Every compression will write some extra data to a stream and will use some extra cpu time to process. I am intrested in something that wil hold only data from files and theirs relative path to streamed folder.

harold aptroot15-Apr-09 14:43

Re: Directory Stream [modified]

15-Apr-09 14:43

Ok great so you didn't read my post Frown | :(

Please try again..

biggy115-Apr-09 15:00

15-Apr-09 15:00

Yes I did read your post. And again thanks for quick reply. Please read this:
wikipedia.org/wiki/Tar_(file_format)

File header
The file header block contains metadata about a file. To ensure portability across different architectures with different byte orderings...

Only thing I need is data from files. Frown | :(

modified on Wednesday, April 15, 2009 9:19 PM

harold aptroot16-Apr-09 1:36

16-Apr-09 1:36

And performance is so important that those couple of hundred bytes is important. Ok. I see no other solution than doing it all manually. Almost everything that exists already will put some bytes into preserving the directory structure.

biggy116-Apr-09 10:21

16-Apr-09 10:21

Thanks for your help. I solved the problem and as you already mentioned I write my own Wink | ;)

It was all night job, but it was worth it.

Watching for Removeable Drives

Xmen Real 15-Apr-09 18:39

Xmen Real

15-Apr-09 18:39

There is no folder/directory stream in DNF. But you can write the entire folder in a binary file using BinaryWriter and Extract all the files from that binary file when require. All you need to think a file format. eg.

int - Number of Files
----For each file----
string - FilePath
int - FileLength
byte[FileLength] - Data
----------------------

-----------------------------------------------
128 bit encrypted signature, crack if you can

Jammer15-Apr-09 12:20

Jammer

15-Apr-09 12:20

Hi All,

I'm trying to find some info on watching for new drives being plugged into the system. The normal kind of drives like Firewire, USB drives, flash sticks, eSata etc.

The FileSystemWatcher seems to only support watching an existing drive. Would WMI be the place to go for this?

Cheers,

Jammer
My Blog | Article(s)

Re: Watching for Removeable Drives

Luc Pattyn15-Apr-09 12:42

Luc Pattyn

15-Apr-09 12:42

search CodeProject for WM_DEVICECHANGE

Smile | :)

Luc Pattyn [Forum Guidelines] [My Articles]

Avoiding unwanted divs (as in "articles needing approval") with the help of this FireFox add-in

Re: Watching for Removeable Drives

Nilesh Hapse15-Apr-09 20:16

Nilesh Hapse

15-Apr-09 20:16

Check this:

Detecting Hardware Insertion and/or Removal[^]

"Legacy code" often differs from its suggested alternative by actually working and scaling.

—Bjarne Stroustrup

Socket Connection Shutdown and Close

kikeman15-Apr-09 11:41

kikeman

15-Apr-09 11:41

Hi,

I have a problem here, In a constructor class I am creating a synchronous socket which I use during this class is alive.

In the destructor of the class I want to Shutdown and Close the socket, but I get a very nice Exception: "ObjectDisposeException was handled" ...

How can I Shutdown and Close the socket when the object is destroyed?

Am I not suppose to shutdown or close the socket by myself?

Example:

~DDLBaseMsg()
{
    if (Sender != null)
    {
        Sender.Shutdown(SocketShutdown.Both);
        Sender.Close();
    }
}

*Developer Day Scotland - Free community conference Delegate Registration Open

Colin Angus Mackay15-Apr-09 12:12

Colin Angus Mackay

15-Apr-09 12:12

You should implement the IDisposable interface and call Dispose from the Finalizer. The code you currently have in the Finalizer should be moved to the Dispose method.

The Dispose method should detect if it is already disposed and not do so again. I suspect that the exception you got was because the Sender was already disposed, but you still had a reference to it.

kikeman16-Apr-09 4:45

kikeman

16-Apr-09 4:45

Hi,

Ok, Thanks for the explanation of the IDisposable, however, I get the same error Frown | :(

The code is simple, I have a form which instantiate the socket owner class CBaseMsg in the constructor:

public partial class FrmMain : Form
{
    CBaseMsg BaseMsg;   //SOCKET INSTANCE CREATED HERE

    //CONSTRUCTOR:
    public FrmMain()
    {
        InitializeComponent();
        BaseMsg = new CBaseMsg();
    }

    //TEST BUTTON
    private void buttonTest_Click(object sender, EventArgs e)
    {
        BaseMsg.SendSomething("Test");
    }
}

The class that instantiates the socket:
What I basically do is to call Dispose() from the Finalizer. I tried also to use the dispose alone, but if I put there a break point it seems that never runs.
As you can see I am not closing nor diposing the Sender instance before calling the dispose method or finalizer. The instances should be "alive" while the form exist.

Should I call dispose of the CBaseMsg from the Dispose of the FrmMain?
Another Question:
Should I really need to Shutdown() the socket? (Close() works just fine in the Finalizer and Dispose()...)

Maybe it is already automatic and I am just investing unnecessary time ...

class CBaseMsg : IDisposable
{
    //Socket Related Connection.
    IPHostEntry ipHostInfo;
    IPAddress ipAddress;
    IPEndPoint remoteEP;
    Socket Sender;

    //CONSTRUCTOR
    public CBaseMsg()
    {
        //Get connected to the server when the object is created.
        // Establish the remote endpoint for the socket.
        ipHostInfo = Dns.GetHostEntry("127.0.0.1");
        ipAddress = ipHostInfo.AddressList[0];
        remoteEP = new IPEndPoint(ipAddress, 55065);

        // Create a TCP/IP  socket.
        Sender = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);
        Sender.ReceiveTimeout = 5000;

        //Get Connected.
        Sender.Connect(remoteEP);
    }

    //FINALIZER
    ~CBaseMsg()
    {
        Dispose();
    }

    public void Dispose()
    {
        if (Sender != null)
        {
            Sender.Shutdown(SocketShutdown.Both);   //EXCEPTION !!
                                                    //ObjectDisposeException was handled !!
            Sender.Close();
        }
    }

    public void SendSomething(string Msg)
    {
        try
        {
            //GET BYTES.
            byte[] buffMsg = new byte[Msg.Length];
            buffMsg = Encoding.ASCII.GetBytes(Msg);

            //SEND TELEGRAM; SYNCHRONOUS
            int bytesSent = Sender.Send(buffMsg);
        }
        catch(Exception ex)
        {
            MessageBox.Show(ex.Message);
        }
    }

}

*Developer Day Scotland - Free community conference Delegate Registration Open

Colin Angus Mackay16-Apr-09 5:05

Colin Angus Mackay

16-Apr-09 5:05

Going by some of your naming conventions I'm guessing you are coming from a C++/MFC background. That being the case you need to think about things a little differently. Well, I suspect you are, but the pendulum has swung too far the other way. You'll get what I mean in a moment.

If you have something that is disposable then you need to dispose of it rather than let the garbage handler deal with it. Just like you do in C++. This is because if it is disposable it will be holding on to resources (like a socket, file handle, GDI resource, etc.) that needs to be cleaned up as soon as you are finished with it rather than when the garbage collector gets around to it.

Finalizers are not run in any specific sequence and you cannot guarantee that the objects you reference haven't already been finalized. Basically, the CLR is clever enough to realise that if you are unreferenced, then everything you reference that isn't referenced else where is also unreferenced. It essentially chucks it into a big queue and processes it but doesn't care about order

Finalizers are really just a backstop in .NET to ensure that if the developer has forgotten to dispose of something the garbage collector can at least get a chance at dealing with it.

Since you only check for nullability on Sender may already have been closed. According to Socket.Shutdown documentation[^] the exception you are getting is raised if you attempt to shutdown a socket that is already closed.

Rather than call Shutdown and Close, you may just want to call Dispose on the socket object which will clean up the Socket for you and can be called multiple times quite safely. If the interface is implemented implicitly then you can just call Sender.Dispose(). If it is an explicity interface you'll have to use ((IDisposable)Sender).Dispose();

I hope this helps.