Yes, that is what "gracefully" means. Another way could be to keep a separate connection with another socket over which you send control information ("file transfer started", "file transfer complete", "file transfer aborted" and so on).

Also, ungracefully closing a TCP connection is not inherently bad, it's only bad in that you may lose buffered data or data in transit that, from the application's perspective, has already been sent (unless the application implements its own acknowledgment protocol on top of TCP). If you're aborting a transfer, you presumably no longer care if the file arrives intact, so it's okay. Just make sure the remote can distinguish between a completed transfer and a prematurely aborted transfer, and make sure the socket is not used for anything else.

Let's say I did that, now I am sending a file through the first socket, and after a while I decided to abort the file transfer, so I send the string "file transfer aborted" through the second socket and then this string is received by the other end, what should the other end do now?

The second end can then "gracefully" close his socket and let the OS clean up in the background while it moves on to other stuff since it now knows the transfer is aborted. That's if you really want to close it gracefully; like I said, if you need to tear down a connection NOW and don't care what happens to the data already committed to the TCP stream, then a hard shutdown is acceptable (to be fair, such situations are rare; when transferring large files it is common to transfer them block by block with, depending on your requirements, periodic status and integrity checking, which allows you to send control information over the same socket with minimal latency).

I'm not sure what level you're working at.

When you say "send a FIN packet" and "send a RST" packet, you talk in terms of the implementation.

If you control the implementation, then you also control what the user has buffered. Thus, you can throw away what the user has buffered, and only keep the bit that is currently "on the wire," which is the size of the remote accept window.

If you want the connection to appear to have terminated gracefully, at the TCP level, then that's what you have to do.

However, some higher-level application protocol will probably be confused. For example, if the protocol says "here comes file X" and then data starts streaming, and then data stops streaming -- should the remote end assume that it has all of X? If there is a length field in the protocol, the remote end will know it didn't receive all of it, so the "graceful" shutdown at the TCP level still ends up being a "forceful/unexpected" shutdown at the application level.

So, if the reason you want to "immediately" stop the transfer is that you changed your mind -- you don't want to send that 20 GB file over your cell phone data plan -- then the best thing to do is to remove all the data that's on the wire as well as all the data that the user has buffered, which means tearing down the connection state, which means sending a RST, and responding with RST if you hear anything more from the other end.

Now -- this is from the point of view of the implementation. When you're writing application software, you typically don't have control at that level, but instead use some particular socket API. In Berkeley sockets (most common,) compare the actions of shutdown() with the actions of close(). They may translate to particular TCP packets on the wire, but there is no guarantee -- there is only the specific defined semantics of those API calls that the application makes.

On Windows, calling closesocket() will be the fastest way for you to close the connection.

Documentation for Winsock closesocket() is here:

https://msdn.microsoft.com/en-us/library/windows/desktop/ms737582(v=vs.85).aspx

Especially this bit:

If the l_onoff member of the linger structure is nonzero and l_linger member is zero, closesocket is not blocked even if queued data has not yet been sent or acknowledged. This is called a hard or abortive close,

Other TCP implementations may do different things -- read your OS man pages!