I’m working with Google Colab and need to understand something weird about file paths. After connecting my Google Drive using the usual method, I noticed that writing files to both “My Drive” and “MyDrive” paths seems to work the same way.
from google.colab import drive
drive.mount('/content/gdrive')
I tested this by creating files in what I thought were different locations:
first_location = '/content/gdrive/My Drive/test.txt'
second_location = '/content/gdrive/MyDrive/test.txt'
# Write to first path
with open(first_location, 'w') as file:
file.write('first content')
# Write to second path
with open(second_location, 'w') as file:
file.write('second content')
Both operations work without any errors. When I check if the files exist, both return True:
import os
print('First path exists:', os.path.exists(first_location))
print('Second path exists:', os.path.exists(second_location))
# Both print True
But here’s the confusing part. When I look at my actual Google Drive, there’s only one test.txt file, and it contains “second content” from the last write operation.
This makes me think that “My Drive” and “MyDrive” are actually pointing to the same folder somehow. But I don’t understand how this works behind the scenes. Are these two different ways to reference the same directory? Is this normal behavior for Google Colab’s drive mounting system?
I’ve also tried using escaped spaces in shell commands, but that creates different issues with path handling. Can someone explain why Colab treats these paths as equivalent?
This behavior occurs because Google Colab creates symbolic links during the drive mounting process. When you mount your Google Drive, the system automatically generates both /content/gdrive/My Drive and /content/gdrive/MyDrive as references to the same underlying directory structure. The reason for this dual naming convention stems from compatibility issues. Google Drive’s actual root folder is named “My Drive” with a space, but many command-line tools and scripts have trouble handling spaces in file paths. To address this, Colab’s mounting system creates “MyDrive” as an alternative path without spaces. You can verify this symbolic link behavior by running ls -la /content/gdrive/ in a code cell. You’ll see that both entries point to the same inode, confirming they’re essentially aliases for identical storage location. This explains why your second write operation overwrote the first one - you were actually writing to the same file twice. For consistent coding practices, I recommend sticking with the “MyDrive” convention since it avoids potential issues with space-sensitive operations and maintains better compatibility across different tools and libraries.
yeah this is totally normal behavoir in colab. basically when you mount gdrive it creates a symlink so both paths point to same location. you can check this by running readlink command on both paths - they’ll show identical targets. its just a convienence thing so people dont have to deal with spaces in folder names.
This happens because of how the Linux filesystem handles the mount point when Google Drive gets connected to Colab. During the mounting process, the system needs to bridge the gap between Google Drive’s web-based storage structure and the local filesystem that Colab runs on. Since Google Drive natively uses “My Drive” as the root folder name, but Unix-like systems often struggle with spaces in paths, Colab’s mounting mechanism automatically creates both versions. Under the hood, they reference the same inode on the filesystem, which is why your file operations affect the same actual storage location. You can observe this behavior more clearly if you create a file using one path convention and then immediately try to read it using the other - you’ll get the same content. This dual-path approach prevents script failures that commonly occur when automation tools encounter spaces in directory names, while still maintaining compatibility with the original Google Drive naming convention.