Understand Linux Hard & Soft Links | Linux LN command [HINDI]

Core idea: Linux links as shortcuts/pointers

• Explains links in Linux as a way to avoid repeatedly using a long file path.
• Compares to Windows shortcuts: create a shortcut in a convenient location, while the actual target stays elsewhere.
• Demonstrates link behavior using ls -l / ls -ltr:
  • In ls -l, the file type column shows:
    • - for normal files
    • l for links
  • The listing can reveal the target path of the link.

Using links (multiple directory entries)

• Shows that you can create multiple links (multiple directory entries) pointing to the same original file.
• Even after deleting one directory entry, other links can still work because they refer to the same underlying target (depending on link type).

Soft link (symbolic link) characteristics

• Soft link is a pointer/shortcut.
• Key behavior:
  • If the original file is deleted, the soft link becomes broken (commonly shown in red in the listing).
  • The soft link still exists, but it no longer points to a valid target.
• Editing behavior:
  • Soft links can be used to read and edit the underlying file.
  • Changes made through the soft link are reflected in the original file.
• Inode behavior:
  • The soft link has a different inode number than the target file (example mentioned: inode 763 for the link vs 765 for the original).

Hard link characteristics

• Hard link is not a pointer; it creates another directory entry to the same inode/data.
• Key behavior:
  • If the original filename is deleted, the data remains accessible via the hard link (i.e., the “link does not break”).
• Inode sameness:
  • Hard link and original file share the same inode number because they reference the same disk data block.
• Why hard links survive deletion:
  • Both names reference the same inode; removing one directory entry doesn’t remove the underlying data as long as another hard link still exists.

Practical/real-life use case (production server)

• Describes a workflow using soft links for versioned application artifacts (example: a Java .jar).
• Scenario:
  • An app expects a fixed filename (e.g., config.xml).
  • New versions create new versioned files (e.g., version2, version3).
• Approach:
  • Keep a soft link named config.xml pointing to the current versioned file.
  • On upgrade:
    • delete the old soft link
    • recreate it to point to the new version
  • Benefits:
    • The application configuration doesn’t need to change.
    • It’s easy to see which version is active.

Main speakers/sources

• The video presenter/instructor speaking in Hindi (single on-camera/voice source; no other speakers mentioned).