10 Local File System
Prerequisites (read first if unfamiliar): Chapter 9.
See also: Chapter 11, Chapter 17, Chapter 31, Chapter 30.
Purpose

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:
Explain the difference between files, folders/directories, paths, and extensions.
Navigate reliably in File Explorer and Finder using core affordances (sidebar, breadcrumbs, search, recent, tags).
Use absolute vs relative paths and understand key path conventions on Windows and macOS.
Adopt naming and organization conventions that scale from one assignment to a multi-month project.
Recognize hidden files, sync-folder behaviors (OneDrive/iCloud), and common pitfalls.
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.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.csvDelete 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 immediatelyPermissions 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 brittlePath(__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.mdSecond, 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\ # WindowsIf 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
Create a project folder structure and explain (in one paragraph) why each folder exists.
Rename 10 files using a consistent naming convention; justify the convention.
Find all
.csvfiles in your course workspace using OS search.Make a “raw data is immutable’’ rule: copy raw data, produce processed data, and document the transformation.
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.

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:
Open a Finder window. Click the Finder smiley face icon in the Dock. If Finder is already active but no window is visible, choose
File→New Finder Windowfrom the menu bar or pressCommand + N.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.
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.See the full path. Enable the path bar via
View→Show Path Bar. You can also right‑click the window title to copy the folder’s full path for use in scripts.Search effectively. Press
Command + Fto search. Use the scope buttons to limit search to the current folder or your entire Mac, and refine results by kind, date, or name.

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:
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.”
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 pressEnterto jump directly. Right‑click the bar to copy the full path.Views and sorting. Use the
Viewtab 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.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.
Chrome.
3 Open Chrome, click the
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.
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
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.
Edge.
6 Open Edge, slick the
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.
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 File→Open. 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.
- 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/, andreports/layouts; useful as a reference even if you do not use the generator.