10  Local File System

Prerequisites (read first if unfamiliar): Chapter 9.

See also: Chapter 11, Chapter 17, Chapter 31, Chapter 30.

Purpose

No Idea Dog Meme: Where Did I Save That File?

Most beginner frustration in computing is not “coding’’—it is losing track of files, confusing locations, and breaking workflows by moving or renaming things. This chapter builds durable habits for accessing, navigating, organizing, and managing files and folders on Windows (File Explorer) and macOS (Finder).

Learning objectives

By the end of this chapter, you should be able to:

  1. Explain the difference between files, folders/directories, paths, and extensions.

  2. Navigate reliably in File Explorer and Finder using core affordances (sidebar, breadcrumbs, search, recent, tags).

  3. Use absolute vs relative paths and understand key path conventions on Windows and macOS.

  4. Adopt naming and organization conventions that scale from one assignment to a multi-month project.

  5. Recognize hidden files, sync-folder behaviors (OneDrive/iCloud), and common pitfalls.

  6. Apply basic safety practices: avoid destructive moves, manage duplicates, and preserve provenance.

Running theme: “Location is a dependency’’

A script, notebook, or application often assumes files are in specific locations. Good file management makes those dependencies explicit and stable.

10.1 A beginner mental model

The smallest piece of vocabulary you need is the difference between a file and a folder. A file is a single named unit of stored data — a report.docx document, a data.csv table, a cleaning.py script. A folder (sometimes called a directory; the words are interchangeable) is a container that holds files, and it can hold other folders too. Folders inside folders form a tree, and your entire computer’s file system is one big tree growing out of a single root.

Every file in that tree has a path, which is the address that points at it. There are two flavors. An absolute path describes where a file is starting from the very root of the tree, so it works no matter where you currently are. A relative path describes where a file is starting from wherever you happen to be right now — it is shorter, but it depends on context. Both kinds use a separator character to divide each step of the descent into the tree, and the choice of separator differs between operating systems: Windows uses a backslash (\), while macOS and Linux use a forward slash (/). On Windows, paths usually start with a drive letter like C:\Users\you\Documents, and there are also network paths that begin with \\server\share. On macOS, the root is just /, your home folder lives at /Users/you, and your Documents at /Users/you/Documents.

Absolute path (Windows):   C:\Users\you\Documents\project\data.csv
Absolute path (macOS):     /Users/you/Documents/project/data.csv
Relative path (either):    project/data.csv         (from inside Documents)
Relative path (either):    ../data.csv              (one folder up)

A practical Windows quirk worth knowing: the operating system has historical limits on how long a path can be, and some tools still trip over paths longer than 260 characters. The mitigation is the same one you would adopt for readability anyway: keep project paths short and avoid burying things ten folders deep.

Each filename usually ends with an extension like .csv, .py, or .docx, separated from the name by a dot. Extensions are how your operating system (and most applications) decide which program to open a file with — .csv opens in Excel or a text editor, .py opens in Python, .docx opens in Word. When you can choose the format you save in, prefer stable plain-text formats like .csv, .txt, and .md over proprietary binary ones (.xlsx, .docx, .pdf). Plain-text files can be read by any tool, version-controlled cleanly with git diff, and recovered from when something goes wrong; binary formats can do none of those things well.

10.2 Access and navigation on Windows

When you open File Explorer on Windows (the icon is a manila folder, usually pinned to the taskbar), you see three things you should learn to recognize: a sidebar down the left with shortcuts to common locations like Quick Access and This PC, a main pane in the middle showing the contents of whichever folder you have selected, and an address bar along the top showing your current location as a sequence of clickable segments. Those segments are called breadcrumbs, and clicking any one of them jumps you back to that folder — so if you are deep inside C:\Users\you\Documents\project\notebooks\drafts, you can click Documents once and land in your Documents folder without using the Back button five times.

Beyond pointing and clicking, File Explorer rewards a few specific skills. Search can be scoped to the current folder or the entire machine, and the difference matters: searching all of This PC for data.csv will find every CSV on your computer, which is rarely what you want, while searching from inside your project folder limits the result to that project. Sort and view options (right-click in the main pane or use the View tab) let you order files by name, date modified, type, or size; sorting by date modified is especially useful when you are trying to remember “what did I save yesterday?” In the View tab there are also two toggles you should know exist before you need them: show file name extensions and show hidden items. The first prevents the classic confusion where data.csv and data.csv.txt look identical to you in the GUI but are completely different files to your code. The second is occasionally needed when troubleshooting .env files, .git folders, or other dotfiles. Turn these on temporarily for diagnostics, and turn them off again when you are done so you do not accidentally delete a system file.

A second important Windows-specific concept is OneDrive sync. If your account uses OneDrive, your Documents folder may not actually live on your laptop — it may live in the cloud, with placeholder files on disk that download on demand when you open them. Sync status icons next to each file or folder tell you what state things are in: a cloud icon means “in the cloud only, not local,” a green checkmark means “always kept on this device,” and a circular arrow means “currently syncing.” For programming and data work, this matters because a script that tries to read a 2 GB CSV will silently trigger a download that may or may not finish before the script tries to use the file. The fix is to right-click any folder you actively work in and select “Always keep on this device,” which forces a full local copy.

10.3 Access and navigation on macOS

Finder on macOS plays the same role as File Explorer on Windows. You open it by clicking the smiley-face icon in the Dock, and you immediately see a sidebar with Favorites and iCloud Drive on the left, a toolbar with view-mode buttons across the top, and the main pane showing whichever folder is selected. The view-mode buttons are worth learning: icon view is good for browsing photos, list view is good for sorting by date or size, column view is the fastest way to drill down through several folders in a row, and gallery view is mostly useful for media. Column view in particular is the best macOS feature for “where am I?” — each column shows the contents of the next level down, so you can navigate a deep folder hierarchy without losing your place.

Finder’s search box (top-right or Command + F) is powerful but defaults to searching your entire Mac. If you only want to search inside the current folder, click the scope button in the search bar and choose the folder name. You can also refine results by file kind, modification date, and other metadata, which is the easiest way to find that “report from last week” you cannot remember the name of. macOS also has tags (the colored circles you sometimes see on file icons), which act as lightweight categories — tag a file as “Course X” or “needs review” without moving it, and then filter by that tag later. Tags are an underused habit that pays off for long-running projects.

A few system folders are hidden by default — the macOS root, the ~/Library folder, anything starting with a dot. Treat them as off-limits unless you have a reason to be there: they hold configuration files for the operating system and your applications, and editing them by mistake can break things in subtle ways. When you do need to see them (most often ~/.ssh for key files, see Chapter 13), the keystroke Command + Shift + . toggles hidden items in any Finder window. Use it for the diagnosis you need, then toggle it off so you do not accidentally drag the wrong thing into the trash.

The macOS equivalent of OneDrive’s “files on demand” behavior is iCloud Drive optimization. If macOS thinks you are running low on disk space, it will quietly evict the least-used files in Documents and Desktop to iCloud, leaving placeholder icons that re-download when you open them. Same problem, same fix: for any folder where you actually run code, make sure the files are present locally. You can confirm by selecting a file and pressing Command + I to bring up the Get Info window, which says whether the file is on your Mac or only in iCloud.

10.4 Organizing work: conventions that scale

The single biggest improvement most students can make to their file management is to stop working out of Downloads/ and Desktop/ and instead create a stable top-level home for everything school-related. The exact name does not matter — School/, Courses/, Coursework/ are all fine — but the existence of one designated place does matter, because it gives every assignment, lab, and project a predictable parent. Inside that home, give each course its own folder, and inside each course folder, separate Assignments/, Labs/, and Project/. The reward is enormous: when you come back to the work in three weeks, you do not have to remember where you put things; you just open the path you always use.

~/Courses/
├── INFO-3010/
│   ├── Assignments/
│   ├── Labs/
│   └── Project/
└── INFO-4040/
    ├── Assignments/
    └── Project/

For data-science projects specifically, one folder layout has become a near-universal standard, and adopting it from day one will save you grief. At the project root you put a README.md describing what the project is and how to run it. You put your inputs in data/raw/ and treat them as read-only — never edit raw data in place, no matter how tempting. Anything derived from those raw files (cleaned versions, joined tables, intermediate aggregates) goes in data/processed/. Reusable Python code lives in src/, exploratory notebooks live in notebooks/, and final figures or tables go in reports/ or figures/. The whole point of the layout is that someone — including future you — should be able to delete data/processed/, run one command, and rebuild it. That property only holds if you respect the read-only rule on data/raw/.

project/
├── README.md
├── data/
│   ├── raw/         # immutable inputs — never overwrite
│   └── processed/   # rebuildable outputs
├── src/             # importable Python code
├── notebooks/       # exploration only, not production
└── reports/         # figures and tables for sharing

Naming conventions are the other lever that pays back compounding interest. Use meaningful, stable names that describe the file’s contents — clean-survey-2026-01.csv instead of data2.csv. Prefix dated artifacts with YYYY-MM-DD so they sort chronologically when you list them: 2026-01-15-pilot-results.csv will always sort next to 2026-01-22-pilot-results.csv no matter what tool you use. Avoid spaces and special characters in any filename you might pass to code — survey results.csv is a recipe for shell quoting bugs, while survey-results.csv or survey_results.csv will work everywhere. And never, ever fall into the final.docx / final-final.docx / final-final-USE-THIS.docx trap. Use dates or version numbers, not adjectives, to track iterations.

The provenance habit is the same idea applied to data. Keep raw files read-only; if you need a variant of one (a smaller subset, a column rename, an encoding fix), save the variant under a new name in data/processed/ and write down in your README or a changelog what you changed and why. The same week, this seems like overkill. Six weeks later, when you cannot reproduce your own results, it is the difference between five minutes of investigation and an afternoon of guessing.

10.5 Search, metadata, and “finding it later’’

Search strategies that work

The single biggest determinant of whether you will ever find a file again is what you named it when you saved it. A file called report.docx is almost invisible to search because dozens of other people in your life have also saved a report.docx; a file called info3010-project1-cleaned-2026-02-15.csv practically jumps out at you. Before you reach for any search tool, it is worth pausing to write a filename you could find from memory in three weeks.

When you do search, the most reliable narrowing is by extension and date modified, not by filename. Both File Explorer and Finder understand queries like kind:csv or ext:ipynb, which immediately drop the result set from “everything on your computer” down to “CSVs on your computer.” Combining that with a date filter (macOS supports date:last week; Windows supports modified:today or a date range) is usually enough to find the file you saved yesterday even if you cannot remember what you called it. The one trick is to remember that search scope matters: make sure you are searching inside the folder you care about, not the whole drive, or you will wait a long time for results you did not want.

Frequently used locations deserve a shortcut. On macOS, drag any folder into the Finder sidebar and it becomes a one-click jump from any window; you can also tag a folder with a colored tag and then click that tag in the sidebar to see every tagged item at once. On Windows, right-click a folder and choose Pin to Quick access to put it at the top of every File Explorer window. In both systems, the payoff is that the folders you open ten times a day are always one click away, which kills any temptation to save things to Desktop “just for now.”

Sort and view for diagnosis

When something goes wrong — a script writes an empty output, a download stalls, a notebook cannot find yesterday’s file — the first diagnostic move is to sort a folder listing by date modified, descending. The most recently touched files bubble to the top, and you can immediately see whether the file you expected to write exists, whether it was written in the last minute, and whether a second stale copy is still hanging around confusing your code. This is the fastest way to answer “what just happened?” without ever running the script again.

The second diagnostic view is the one that shows size and type as columns. Switch Finder to List view (Command + 2) or File Explorer to Details view, then add Size and Type if they are not visible. A 0-byte data.csv is almost certainly a failed download or a script that opened a file for writing and crashed before writing anything. A dataset.csv that is suddenly 12 GB instead of 200 MB means somebody — probably a runaway loop — appended much more than expected. Neither problem would be visible in icon view; both are obvious the moment you look at the size column.

# What "sort by date modified" typically reveals
data/processed/   2026-03-14  10:42   <DIR>
  cleaned.csv     2026-03-14  10:42      5,418,220   <-- what you just wrote
  cleaned.csv~    2026-03-14  10:39         12,004   <-- editor backup, ignore
  cleaned.csv.tmp 2026-03-14  10:41              0   <-- aborted write, delete

10.6 File operations and safety

Copy vs move vs rename

Three operations look nearly identical in a file manager but have very different consequences for any code that touches those files. Copy leaves the original in place and produces a second, independent file — changes to one do not affect the other. This is the safe choice whenever you want to experiment: copy dataset.csv to dataset-experiment.csv, mangle the copy however you like, and if anything goes wrong you throw the copy away and the original is untouched. Move takes the single file and changes where it lives; there is still only one file, but its path is different now. Rename is even more subtle: the file is still in the same folder, but its identity — the thing every script and notebook knows it by — has changed.

The practical rule is that copy is almost always safe, while move and rename break any code that mentions the old path. A notebook cell that says pd.read_csv("data/raw/survey.csv") silently stops working the moment you rename survey.csv to survey-2026.csv, and the error you see next time you run it (FileNotFoundError) gives no hint that the file is fine and the code is the one that got stale. Before you move or rename anything that code depends on, search the project for any reference to the old name — most editors have a “find in folder” command that will find it in seconds — and update the references in the same commit as the rename.

# Copy: safe, makes a second independent file
cp data/raw/survey.csv data/raw/survey-backup.csv

# Move: single file, new location (may break code that references old path)
mv data/raw/survey.csv data/archive/survey-2025.csv

# Rename: single file, new name in the same folder (same risk)
mv data/raw/survey.csv data/raw/survey-2026-01.csv

Delete and recover

The Trash on macOS and the Recycle Bin on Windows are not deletion — they are a holding area. A file you drag to the trash stays on disk, taking up the same amount of space it always did, until you explicitly empty the bin. That forgiveness is deliberate: if you realize five minutes later that you needed important.csv, you can still recover it with a right-click and “Put Back.” Only when you empty the bin, or use a shortcut like shift-delete on Windows, does the file become genuinely hard to recover. Treat every “empty trash” action as the destructive step it is, and get in the habit of looking at what you are about to empty before you confirm.

A few operations skip the bin entirely and go straight to permanent deletion, and you should know which ones. On a network drive or a USB stick, Windows often deletes files outright because the bin lives on the local drive. In the terminal, rm (on macOS and Linux) and del (on Windows) do not use the bin — the file is gone the instant the command returns. And any “sync” tool, from OneDrive to iCloud to Dropbox, will propagate a deletion across every device within seconds, which is great until it is not. When in doubt, prefer the GUI for deletions you can reverse and be extra deliberate with terminal deletions.

# GUI trash: reversible
# macOS:    drag to Trash, then "Put Back" if needed
# Windows:  Delete key or drag to Recycle Bin, then "Restore"

# Terminal: NOT reversible on most systems
rm data/processed/old-output.csv   # gone immediately

Permissions basics (just enough)

On both macOS and Windows, every file carries a short record of who is allowed to read it, write to it, and (for scripts and programs) execute it. Most of the time you never think about this, because you own the files in your own home folder and you have full rights over them. Permissions only become visible when something goes wrong, and the error message is usually something like Permission denied, Access is denied, or Operation not permitted. All three are the operating system saying, “You, specifically, are not allowed to do that to this file.”

When you see one of those errors on a file you expected to own, there are only a few likely explanations. The first is that you are trying to write to a folder outside your home directory — /Applications on macOS, C:\Program Files on Windows, anything that requires administrator rights. Move the file into your home folder and the problem disappears. The second is that the file came from somewhere else — a USB stick, a zip downloaded from the web, a shared network drive — and it was created with different owner metadata that does not match your account. Copying (not moving) the file into your own folder usually fixes this. The third, more specific to macOS, is Gatekeeper refusing to run a script downloaded from the internet. The fix for that lives in Chapter 9.

The general habit that prevents permission problems is to do your real work inside your user home directory and treat everything outside it as read-only. ~/Courses/, ~/Projects/, ~/Documents/ — all fine. /usr/local/, C:\Windows\, /System/ — all off-limits. If a tutorial ever tells you to sudo something while you are still learning, pause: there is almost always a safer path that does not require administrator rights, and using them casually is the single fastest way to break your computer.

10.7 Common student pitfalls (and how to avoid them)

A small number of mistakes account for almost all the file-management pain that beginners suffer, and they are all preventable. The most common one is working out of Downloads/ or Desktop/ forever: every assignment lands wherever it was downloaded, duplicates accumulate, version final-2.csv ends up next to final-3.csv next to data.csv, and three weeks later nothing can be found. The fix is the one from the previous section — create a stable project root under Courses/ or Projects/ and move work there immediately, every time.

The second is confusing cloud sync with local storage, which usually shows up as a notebook that cannot find the data file you can clearly see on your screen. The file is not really there; it is a placeholder that OneDrive or iCloud is going to download on demand, and your code reached the read before the download finished (or while you were offline). The fix is to make the project folder always-local: right-click and “Always keep on this device” on Windows, or “Download Now” / “Keep Downloaded” on macOS, before you ever try to run the code.

The third is accidental extension changes, where you rename data.csv to data (because the GUI was hiding the extension and you thought you were renaming the whole filename), or where you save a CSV “as text” and end up with data.csv.txt. Both produce the same kind of confusing failure: the file opens in the wrong program, or your code says “no such file.” The fix is to turn on show file extensions in your file manager and leave it on. The few seconds of cognitive overhead are worth never being burned by this again.

The fourth is moving folders after you have written code that depends on them. A script that references data/input.csv works fine until you reorganize and the data file moves. The fix is twofold: pick your project root early, do not move it casually, and inside the project use relative paths so that everything is stable as long as the project root stays put. If you must use absolute paths, compute them at runtime from __file__ rather than hard-coding /Users/alex/..., since hard-coded absolute paths immediately break when anyone else clones the project — including future you on a different laptop.

10.8 Bridging to the terminal and programming

Why file habits matter for code

When you run a script or a notebook, the operating system hands it a single piece of context that quietly controls almost every path it will ever read or write: the current working directory, or CWD. A relative path like data/raw/survey.csv is not an address on disk; it is an instruction to “start from the current working directory, then look for a folder called data, then a folder inside that called raw, then a file called survey.csv.” Change the CWD, and the same path means something completely different — or nothing at all.

This is why the advice earlier in the chapter — keep a stable project root, and launch your code from that root — is more than just tidiness. A notebook that works perfectly when you launch Jupyter from ~/Courses/INFO-3010/Project/ will throw FileNotFoundError for the same line of code if you launch it from ~/Courses/INFO-3010/, because one extra level up means the data/ folder is nowhere in sight. When something breaks, always check the CWD before you change the code:

# macOS / Linux — print the current working directory
pwd

# Windows PowerShell
Get-Location
# From inside Python or a notebook cell
import os
print(os.getcwd())

The corollary is that hard-coded, machine-specific absolute paths are a code smell. A line like pd.read_csv("/Users/alex/Downloads/survey.csv") will work on exactly one laptop, owned by one person, until the day they move the file. Nobody else who clones the project — including you six months from now, on a new machine — can run it without editing the source. Relative paths anchored to the project root are portable for free; keep them.

Cross-platform path handling (conceptual)

If you only ever use macOS or only ever use Windows, path handling is usually invisible. The moment you share code with someone on the other platform, though, the separator character (/ vs \) and the shape of the root (/Users/... vs C:\Users\...) start producing subtle bugs that are hard to track down. The safe habit is to stop writing paths as strings at all and instead use whatever path-handling utility your language provides. In Python, that utility is pathlib, and it is worth learning on day one:

from pathlib import Path

# Good: portable, works the same on Windows and macOS
project_root = Path(__file__).resolve().parent
raw_data     = project_root / "data" / "raw" / "survey.csv"
df = pd.read_csv(raw_data)

# Bad: breaks on the other operating system
df = pd.read_csv("data\\raw\\survey.csv")   # Windows-only
df = pd.read_csv("data/raw/survey.csv")     # usually fine, but brittle

Path(__file__).resolve().parent is the trick that makes a script find its own folder no matter where it is launched from: the script asks the operating system where its own source file lives, resolves any symlinks, and uses that as the anchor for all subsequent paths. Every relative path is then built by joining with the / operator, which pathlib translates into whatever separator the current operating system wants. (See Chapter 17 for when to bring this discipline from notebooks into reusable scripts, and Chapter 31 for how the project layout interacts with version control — data/raw/ typically belongs in .gitignore, while src/ and notebooks/ do not.)

Two small supporting habits make everything else smoother. Keep paths short — deep project trees hit Windows’ legacy path-length limits and make every error message harder to read — and avoid special characters in filenames you pass to code. Spaces, parentheses, accented letters, and curly quotes all work in the GUI and all occasionally break in the terminal or a script. Stick to letters, digits, hyphens, and underscores for anything a script will touch, and you will never need to learn which layer of which tool is responsible for the broken quoting.

10.9 Stakes and politics

A “local” file system is less local than it used to be. The biggest political shift in personal computing over the last fifteen years has been the migration of student work from the laptop’s own disk into corporate cloud sync — OneDrive, iCloud Drive, Google Drive, Dropbox. The migration is sometimes a deliberate choice and sometimes a default: a Windows laptop signs in to a Microsoft account and your Documents folder is silently rewired to OneDrive, with placeholder files where bytes used to be.

Two consequences worth naming. First, who controls the bytes. Files in cloud-synced folders live on the vendor’s storage, governed by their terms of service; deletion, recovery, account suspension, and law-enforcement requests are now the vendor’s decisions to make, not yours. Second, who pays for sync’s failures. When a sync conflict produces “myfile (alex’s MacBook Pro).docx” or a network blip leaves a placeholder where a script needed real bytes, the cost of debugging the mismatch between what the GUI shows and what the disk holds falls on the user — almost always a non-specialist who is being asked to reason about a layered system they did not choose.

See Chapter 8 for the broader framework. The concrete prompt to carry forward: when you decide where a project lives, ask whose rules the storage runs under and what happens when the network is gone.

10.10 Worked examples

Building a course workspace from scratch

You are starting a new semester with three classes. The first thing to do, before you download any handouts, is to create the home that will hold all of them. Open a terminal in your user directory and run:

mkdir -p ~/Courses/INFO-3010/{Assignments,Labs,Project}
mkdir -p ~/Courses/INFO-4040/{Assignments,Project}
mkdir -p ~/Courses/STAT-2010/{Labs,Assignments}

(On Windows, do the same in PowerShell with New-Item -ItemType Directory -Force -Path or just create them by right-clicking in File Explorer.) Then add the top-level Courses folder to your file manager’s favorites: drag it to the Finder sidebar on macOS, or right-click and choose “Pin to Quick access” in File Explorer on Windows. From this point on, every assignment you save lives somewhere predictable, and you can get to any of them in two clicks.

Turning a messy Downloads folder into a clean project

You started a project a month ago by downloading a few CSVs into ~/Downloads/ and writing some throwaway code. Now there are seventeen files mixed up with a semester’s worth of unrelated downloads, and the project is starting to matter. Time to rescue it.

The mechanical version of the rescue is just three steps. First, create the new project root and the standard subfolders:

mkdir -p ~/Courses/INFO-3010/Project/{data/raw,data/processed,src,notebooks,reports}
cd ~/Courses/INFO-3010/Project
touch README.md

Second, move the project files out of Downloads. Sort Downloads by date or by filename to identify them, and move everything related to this project — *.csv data files into data/raw/, notebooks into notebooks/, scripts into src/ — into the new project. Third, open every script and notebook, find any path that points at ~/Downloads/something.csv, and rewrite it to a relative path like data/raw/something.csv so the project no longer depends on the absolute location of your old Downloads folder. Run the code from the project root once to confirm everything still works. Now the project is portable, reproducible, and almost impossible to lose.

Diagnosing “file not found”

You run a script and Python tells you FileNotFoundError: data/input.csv. Resist the urge to immediately edit the path. Instead, gather evidence in three short steps. First, confirm the file actually exists where you think it does by listing the directory:

ls -la data/        # macOS / Linux
dir data\           # Windows

If input.csv does not appear in the listing, the bug is not in the code — the file is genuinely missing or has a different name (a trailing space, a typo, a .csv.txt extension you cannot see). Fix the file or the filename; do not fix the code.

If the file does appear in the listing but Python still cannot find it, the second check is your current working directory:

pwd                 # macOS / Linux  (Windows: cd with no arguments)

A relative path like data/input.csv is interpreted relative to whatever directory you launched Python from. If you launched Python from the project root, data/input.csv works. If you launched it from inside notebooks/ or src/, the same path no longer resolves. Either cd to the project root before running, or rewrite the path so it is computed from __file__.

The third check, only if the first two pass, is whether the file is sync-stranded: you can see a placeholder for it but the bytes are still in the cloud. On macOS you can confirm with Command + I in Finder; on Windows the sync icon next to the file tells you. Force a local copy and try again. Most “file not found” errors will be solved by one of these three checks; only after all three should you start looking at code.

10.11 Exercises

  1. Create a project folder structure and explain (in one paragraph) why each folder exists.

  2. Rename 10 files using a consistent naming convention; justify the convention.

  3. Find all .csv files in your course workspace using OS search.

  4. Make a “raw data is immutable’’ rule: copy raw data, produce processed data, and document the transformation.

  5. Break and fix: move a folder referenced by a notebook/script; then repair it using relative paths.

10.12 One-page checklist

  • I know where my project root is.

  • My project uses a consistent folder structure.

  • Raw data is preserved and not edited in place.

  • Filenames are descriptive, stable, and machine-friendly.

  • I can find files by search (extension/date/keyword).

  • I understand whether files are local or cloud-on-demand.

  • I can show extensions/hidden items when troubleshooting and hide them afterward.

  • I avoid working in system directories and respect permissions.

10.13 Quick reference: key locations

Windows (typical)

  • User home: C:\Users\\

  • Documents/Downloads/Desktop under user home

  • OneDrive folder (if enabled): typically under user home

macOS (typical)

  • User home: /Users//

  • Documents/Downloads/Desktop under user home

  • iCloud Drive appears in Finder sidebar; local availability may vary with storage settings

Your computer’s “file system” is the hierarchy of folders and files where programs and documents are saved as well as the software and hardware for storing and retrieving these data. Windows and macOS are very different operating systems with very different underlying file systems. It is really important that you are able to access and navigate through your computer’s file system for everything from downloading files to configuring options. This section will cover how to familiarize yourself with your computer’s file system, the location of some important folders, and navigating to new folders you create. In this section, you will do this using the graphical user interfaces (GUI) in macOS or Windows.

The macOS Finder icon.
macOS Finder.

The “Finder” application is the primary graphical user interface for interacting with the macOS file system.1 Finder is always running in the background when you are using macOS. A few core actions will help you orient yourself:

  1. Open a Finder window. Click the Finder smiley face icon in the Dock. If Finder is already active but no window is visible, choose FileNew Finder Window from the menu bar or press Command + N.

  2. Navigate via the sidebar. The sidebar lists common locations (Favorites, iCloud Drive, Downloads, Applications). Clicking a folder shows its contents in the main pane. Use the back and forward buttons to move through history.

  3. Choose a view. Use the toolbar buttons or View→ menu to switch between icon, list, column, and gallery views. Column view is especially useful for seeing the folder hierarchy and previewing files without opening them.

  4. See the full path. Enable the path bar via ViewShow Path Bar. You can also right‑click the window title to copy the folder’s full path for use in scripts.

  5. Search effectively. Press Command + F to search. Use the scope buttons to limit search to the current folder or your entire Mac, and refine results by kind, date, or name.

The Windows File Explorer icon.
Windows File Explorer.

Windows File Explorer is the graphical tool for navigating the file system on Windows. Open it by clicking the folder icon in the taskbar, pressing Windows + E, or selecting File Explorer from the Start menu. Key concepts include:

  1. Navigation pane. The left‑hand pane contains Quick Access (pinned and recent folders), This PC (drives and user folders), and network locations. Click an entry to display its contents in the main pane. Pin frequently used folders to Quick Access by right‑clicking and choosing “Pin to Quick access.”

  2. Address bar and breadcrumbs. The address bar shows your current path as clickable segments (breadcrumbs). You can type a path (e.g., C:\Users\name\Documents) and press Enter to jump directly. Right‑click the bar to copy the full path.

  3. Views and sorting. Use the View tab or the layout buttons to switch between details, list, tiles, or large icons. Sort by name, date modified, type, or size to locate files quickly.

  4. Search box. The search box in the top‑right corner searches within the current folder by default. Combine it with filters like kind or date (via the Search tab) to narrow results. Remember that searching the entire drive can take time.

File paths.

A “file path” is an address that describes where a folder or file lives on your computer. The file paths for Windows and macOS use different formats and the commands for navigating and accessing each are not compatible. I am going to use my personal Mac and PC computers as an example; the file paths on your computer will be different. My “Downloads” folder on my Windows has a file path of C:\Users\Brian\Downloads. The C:\ is the name of the primary hard drive on almost every PC.2 My “Downloads” folder on my macOS has a file path of /Users/Brian/Downloads.

2 If you have multiple hard drives,

Note on drives and separators. Windows may assign other drive letters (D:, E:, etc.) if you have multiple hard drives or partitions. Replace C:\ with the correct letter when constructing paths. Also remember that Windows uses backslashes (\) to separate path components, whereas macOS and Linux use forward slashes (/). This difference matters when typing paths in the terminal or code.

10.14 Why can’t I find a file I downloaded from Canvas? Where did it go?

Building on the ideas about your computer’s file system from the previous section, it is important to know where to find the files we download using our web browser. Depending on the defaults and other preferences of your web browser, downloaded folders might go to your Desktop, a Downloads folder, or some other place. The steps below will make sure that your browser is downloading the folders to a consistent location: your Downloads folder. Instructions for changing the download location of the most popular web browsers (Chrome, Safari, Firefox, and Edge) are listed below with links to their official documentation or other tutorials.

Figure 10.1: Changing the Chrome download location.
Chrome.

3 Open Chrome, click the hamburger menu icon button in the upper right corner, select “Settings”, and scroll to the bottom and click “Advanced”. Under the “Downloads” section, click “Change”. Use the Finder (macOS) or File Explorer (Windows) window that pops up to navigate to your “Downloads” folder and click “Select Folder”. See Figure 10.1.

Figure 10.2: Changing the Safari download location.
Safari.

4 This should be set to your “Downloads” folder by default but here are the steps to change it. Open Safari, select “Safari” from the menu bar, and click “Preferences…”. In the “General” tab, click the drop-down next to “File download location. User the Finder window that pops up to navigate to your”Downloads” folder. See Figure 10.2.

Mozilla.

5 Open Firefox, click the hamburger menu icon button in the upper-right, and select “Settings”. In the “General” panel, scroll down to the “Files and Applications” section, and click the “Browse…” button. Use the Finder (macOS) or File Explorer (Windows) window that pops up to navigate to your “Downloads” folder and click “Select Folder”. See Figure 10.3.

Figure 10.3: Changing the Firefox download location.
Edge.

6 Open Edge, slick the three-dot menu icon button in the upper-right, and click “Settings”. Select “Downloads” in the menu on the left and in the “Location” area click the click the “Change” button. Use the File Explorer window that pops up to navigate to your “Downloads” folder and click “Select Folder”. See Figure 10.4.

File types.

Note that some file types like PDFs may open by default in your web browser rather than saving to your Downloads folder. Some other types of files like DOC or XLS may open in Word or Excel by default and are saved in arcanely-named and impossible-to-find temporary folders. If you want to be able to work with these files after you have downloaded them, make sure to use the “Save as” functionality in the browser, PDF reader, Office application, etc. to move it to a more appropriate location like a “Downloads” or class-specific folder. The details on how to do this are specific to that application: use the documentation links provided for the browsers in the previous section to search for information and tutorials if you are having trouble.

Figure 10.4: Changing the Edge download location.

10.15 What does it mean to unzip a file? How do I do that?

Compressed zip files are archives that bundle one or more files into a single package and reduce their size. Before you can work with the contents, you need to unzip (extract) the archive. Both Windows and macOS provide built‑in tools to handle zip files, and many third‑party tools exist. The basic workflow is the same:

On Windows.

Locate the .zip file in File Explorer. Right‑click the file and choose “Extract All…” from the context menu. A dialog will ask where to extract the files; by default it creates a folder with the same name as the zip file in the current directory. You can browse to choose a different location. After extraction completes, open the new folder to access the files. It is safe to delete the original zip file once you have verified that the extraction succeeded.

On macOS.

Double‑click the .zip file in Finder or select it and choose FileOpen. Archive Utility will automatically decompress the archive into a folder alongside the zip file. If you need more control, you can right‑click and select “Open With → Archive Utility” or use a third‑party app such as The Unarchiver. After unzipping, a folder with the same name appears; open it to access the extracted files. You can move this folder into your project structure and delete the original zip file.

Safety tips.

Never run executables from a zip file you downloaded unless you trust the source. Always choose a destination folder you can locate easily (for example, your “Downloads” folder or a course project folder), and avoid unzipping directly into system folders. Keep raw zipped archives if you need to preserve the original state for provenance, but otherwise deleting them saves space.

Note📚 Further reading
  • Microsoft, File Explorer in Windows — the official walk-through of navigating Windows paths.
  • Apple, Finder User Guide for Mac — covers tags, column view, and search.
  • Python docs, pathlib — the cross-platform way to work with paths from code; learn it on day one and never touch a backslash again.
  • Hadley Wickham and Jenny Bryan, What They Forgot to Teach You About R: project-oriented workflow — the canonical short essay on setwd() antipatterns and project-relative paths; the lessons translate directly to Python.
  • The Turing Way, Project structure — community-maintained guide to reproducible project layouts in research contexts.
  • Cookiecutter Data Science, Directory structure — a widely adopted template for data/, src/, notebooks/, and reports/ layouts; useful as a reference even if you do not use the generator.