# Shortest code for infinite disk I/O

(Just open 50 tabs in Google Chrome :D (just kidding, no you can't))

Shortest code for infinite disk I/O any language, C# example:

using System.IO;

namespace FileApp {
static class Program {
public static void Main() {
do {
File.WriteAllText("a", "a");
File.Delete("a");
} while (true);
}
}
}

You can't just fill the entire disk though, as then it would halt in the end and would be finite.

And you can't do reading only, infinite writing has to happen. (It has to kill my SSD after enough runtime.)

Get cracking! :)

• Does reading files instead of writing them also count as disk I/O? What about writing to /dev/null? (Is yes>/dev/null a valid Bash answer?) – Doorknob Apr 1 '16 at 12:33
• Can it take any input ? – User112638726 Apr 1 '16 at 14:22
• Dang man...what did your SSD do to you? – R. Kap Apr 1 '16 at 23:14
• As I can't hope to compete with 6 byte solutions, would creating the file ./a with the 3 byte contents ./a count for a bonus prize for lateral thinking? AFAIK just executing a file causes some file system writing to take place on many systems, because at the very least 'last access time' gets updated as a byproduct ;-) – Stilez Apr 2 '16 at 13:57
• Many of these answers will write the data into the same space over and over. That does not result in an actual disk write even if the data differs. (Extreme case, dos -> windows communications. I wrote 4k of data in dos and read it back in Windows--so long as data was flowing the disk light would stay off.) – Loren Pechtel Apr 2 '16 at 23:40

## DOS/Batch: 4 bytes

%0>x

This batch file will call itself (%0) and redirect (>) the output to a file called x. Since echo is on by default, this will output the path and command.

• Will this run out of disk space eventually, or is the output overwritten? – MathuSum Mut Apr 11 '16 at 12:46
• @MathuSumMut: With > it will be overwritten. >> would append – Thomas Weller Apr 11 '16 at 20:15
• You win then I guess :P – MathuSum Mut Apr 11 '16 at 20:39
• @ΈρικΚωνσταντόπουλος: That's true. In that case, a file with 0 byte is produced, not generating I/O as expected by this challenge. But it's not our task to consider every case, otherwise you might want to turn off caching, virus scanners, ... – Thomas Weller May 24 '16 at 19:17
• Writing a 0 byte file will still cause disk I/O, as it has to update the last-modified time within the directory. – user62131 Dec 13 '16 at 14:43

## PowerShell v2+, 10 bytes

for(){1>1}

Simply loops infinitely with an empty for loop. Each iteration, we output the integer 1 (implicitly converted to a string) with the > redirect operator, which overwrites the file named 1 in the local directory.

• Could you replace the second 1 with anything else (that makes a valid file name) or does it have to be 1? – Nic Hartley Apr 1 '16 at 21:53
• On my Windows VM, Winload.exe is sufficient... – Comintern Apr 1 '16 at 23:07
• I think it has to be a number because if it is a letter then it would be treated as a variable, to treat it as a string quotes are required, and they waste bytes. :P – MathuSum Mut Apr 2 '16 at 15:14
• @QPaysTaxes MathuSum has it correct. The second 1 needs to be a number of some sort in order for the implicit parsing to work correctly. Anything from [0-9] would work the same. – AdmBorkBork Apr 4 '16 at 12:17
• @Nacht Maybe it's a quirk of my particular environment, then. In my ISE (PSv4 Win8.1), replacing the second 1 with anything non-numeric (and not specified either as .\a or a.txt or the like) results in a parse error. – AdmBorkBork Apr 5 '16 at 12:21

# Pyth, 6 bytes

#.w]]0

Pyth's only file output command is .w. When called on a string, it writes that string to a file in append mode, which is no good for the purpose of this question. When called on a 2-d array, it writes the corresponding image to that file, overwriting the file contents. That's what this program does. The default file output name is o.png, so this program infinitely overwrites the file o.png with a 1-pixel white image. # is an infinite loop.

If you want a shorter (but more boring than my other one) answer:

# Bash, 5 bytes

>w;$0 I could make that shorter if there's a command (less than 3 bytes long) that writes something to disk I/O. Something like sync would work, but sync is 4 bytes 😛 Note: this doesn't work when run straight from bash, only when put in a script and run as the script name. (i.e. echo 'w>w;$0' > bomb; chmod 755 bomb; ./bomb)

• Looks like it's a tie between me and @isaacg - who wins? – Daniel Apr 2 '16 at 3:09
• I prefer using exec (or . $0). I think this will run out of PIDs. – muru Apr 2 '16 at 8:30 • Is the first w needed here? For me simply >w creates an empty file w, and doing that in a loop will create infinite I/O because the mtime metadata needs to be updated continually. – Henning Makholm Apr 3 '16 at 12:17 • If that qualifies @HenningMakholm then I'll put it in. – Daniel Apr 3 '16 at 13:29 • The script only contains these bytes. Since it's bash there's no compiler or anything fancy needed. – Daniel Apr 4 '16 at 13:33 ## Ruby, 22 20 bytes loop{open(?a,?w)<<1} Repeatedly truncates and writes a 1 to the file a. Thanks to Ventero for 2 bytes! • open(?a,?w)<<1 to save 2 bytes. – Ventero Apr 1 '16 at 15:29 • Thank you, doorknob, for honouring us with your presence. I am humbled. – MathuSum Mut Apr 3 '16 at 10:59 • Does that leak file descriptors? Or does it get closed when it goes out of scope? (IDK Ruby, sorry). – Peter Cordes May 14 '16 at 6:31 # cmd, 14 bytes :a cd>1 goto a Infinitly overwrites the file 1 with the string to the current directory I'm new here: Are windows new lines (CR LF) counted as two bytes? • Welcome to PPCG! Windows, at least modern systems, should be able to handle just LF without issue. The above works for me with just LF on Windows 8.1, so your 14 bytes is correct. – AdmBorkBork Apr 1 '16 at 15:34 • CR LF2CR1LF1 – Erik the Outgolfer May 15 '16 at 15:50 # Bash + coreutils, 10 yes \>b|sh Writes a continuous stream of >b, which is piped to sh for evaluation. >b simply truncates a file called b to zero bytes each time. • +1 because your name is really appropriate to what this snippet of code will do – Olivier Dulac Apr 4 '16 at 17:43 • Why b and not c? – CalculatorFeline Jun 5 '17 at 2:17 # Perl 5, 2732 22 bytes {{open my$h,'>o'}redo}

If simply changing the modification timestamp of a file suffices...

Quick explanation:

{ # Braces implicitly create/mark a loop.
{ # They also create closures, for my variables.
open my $filehandle, '>', 'o'; # Writing to file "o". # close$filehandle;   # Called implicitly when
# variable gets destroyed.
} # $filehandle gets destroyed because there are no references to it. redo; # ...the loop. } Previous solution (32 bytes): {{open my$h,'>o';print$h 1}redo} Edit: {open F,'O';print F 1;redo} ← Didn't test the code before posting; now I had to correct it. • :o a perl variable not prefixed with$! – cat Apr 2 '16 at 2:22
• @cat: It's not a regular variable, like a scalar, array, or hash. It is simply a bareword. Depending on context, a bareword can be taken as a sub (a function), a glob, I think, or a filehandle. (Maybe others too?) – g4v3 Apr 4 '16 at 7:46

## PHP, 60 30 17 16 15 bytes

Updated yet again as per @manatwork suggested:

while(!cd>1);

Also now tested.

A bit of cheating 22 bytes:

while(exec('>1 dir'));

Earlier suggestion by @manatwork 30 bytes:

while(file_put_contents(1,1));

NOT TESTED (no php available on this computer) 43 bytes:

for($a=fopen(1,'w');fputs($a,1);fclose($a)) A golfed original 45 bytes:$a=fopen(1,'w');while(fputs($a,1))rewind($a);

My first post here, joined because I just had to try this out: as long as file write succeeds, rewind file pointer to start.

Just can't get smaller than the file_put_contents().

• while(file_put_contents(1,1)); should be enough. Note that running full scripts from command line as php -r '…' is acceptable as per consensus on meta Running PHP with -r instead of code tags. – manatwork Apr 1 '16 at 13:13
• Is this actually writing to disk or just a buffer in memory? – Brice M. Dempsey Apr 1 '16 at 14:33
• @manatwork Oh man! I knew there's always room for improvement, but that much... too bad that function hasn't got shorter name. :D I don't know about the buffer.. I wonder if I should update the answer with that shorter solution. – diynevala Apr 1 '16 at 18:47
• If it's shorter, please do update your answer, go ahead! :) – MathuSum Mut Apr 1 '16 at 21:35
• Is it allowed to call exec() from php? I realize it is no more in php's "scope". – diynevala Apr 2 '16 at 5:59

• :>l;exec $0 - file creation is writing the inode – user24582 Apr 1 '16 at 14:50 • Even though you delete y, yes will still continue to write to the same file handle that it had. Run lsof | grep yes and you should see something like /path/to/y (deleted). This will fill up the disk and fail. – muru Apr 2 '16 at 8:43 • Instead of rm y you can use >y which will truncate the existing file. It is also a bit shorter. – aragaer Apr 2 '16 at 21:47 # TI-BASIC, 12 bytes While 1 Archive A UnArchive A End Alternate solution by user lirtosiast with the same size: While 1 SetUpEditor Archive ∟1 End This will work on the TI-83+ and TI-84+ series of calculators. Yes, this also works if A is already archived or is not initialized at all at the start of the program! The program is only 12 bytes because of tokenization. • I don't know if the flash memory used by the calculators counts as "disk". – lirtosiast Apr 3 '16 at 21:01 • @lirtosiast In Jamy's defense, SSDs are made of flash memory =) – Cort Ammon Apr 4 '16 at 0:37 • In any case, the byte count is at least 10 bytes less. The 2nd Mem screen counts a header equal to 9 bytes + the length of the program name, but we don't here so you can subtract it out. – lirtosiast Apr 4 '16 at 1:27 • @lirtosiast This repeatedly writes and reads to the ROM (permanent memory) of the calculator, not the RAM. Of course, calculators don't have an actual hard drive inside :) – Jamy Mahabier Apr 4 '16 at 17:57 • @lirtosiast Thanks, I didn't know about that! (I was wondering why the amount of bytes my TI-84+ reported didn't match up with my hand-counting...) I've updated my answer. – Jamy Mahabier Apr 4 '16 at 18:05 # CPython 3.5, 33 16 bytes while 1:open("a") Yes, really. :D • while 1:open("a","w") is shorter and strace shows that python is doing open, fstat64 and close, definitely I/O operations. If the file a already exists, it can be even shorter: while 1:open('a') which still generates an open, fstat64 and close, and even modifies atime of the file. – Radovan Garabík Apr 5 '16 at 11:00 • @RadovanGarabík :0 Thank you, I didn't know that handy piece of information! Of course, it's implementation specific. – cat Apr 5 '16 at 11:26 # MATL, 10 bytes 1[]T3$Z#T

### Explanation

This is an infinite loop that writes number 1 to a file called inout in current directory, overwriting previous file's contents.

% do...while loop
1     %   push number 1
[]    %   push empty array
T     %   push "true"
3$Z# % fwrite function. First input is file content. Second is file name; % defaults to "inout" if empty. Third indicates that any previous % file contents should be discarded T % push "true": loop condition % implicitly end loop. Loop condition is "true", so the loop is infinite ## Haskell, 20 bytes f=writeFile"b""a">>f Write the string "a" to a file named "b" and repeat. writeFile overwrites the file if it exists. ## JavaScript (Node.js), 43 41 bytes (c=x=>require("fs").writeFile("a",x,c))() Writes null to a file named a, then repeat. • What about writing c or x to the file? Saves 2 bytes. Also, doesn't requirefs work? – Charlie Apr 7 '16 at 14:43 • @Charlie Good point with writing c or x. requirefs unfortunately doesn't work, because using backticks to call a function calls it with the first arguments as ["fs"] (array, which first and only element is the passed string) instead of "fs" (just the string). Try console.logtest for example. – Michał Perłakowski Apr 7 '16 at 15:02 # ZSH, 14 bytes for ((;;)) :>: Zsh, unlike Bash and other Bourne-like shells, allows loops without the do ... done fence, provided the condition is suitably delimited. Alternatively, with while: while {} {:>:} Note that : is a builtin. You can't suspend this loop. The principle is the same as in Digital Trauma's answer - nothing is written to the file, the IO is purely from creating and truncating the file. • I gotta say, I never thought I'd see muru, the muru, come play Code Golf. Welcome to PPCG :D – cat Apr 2 '16 at 10:58 • @cat Thanks. :D I have played once before. – muru Apr 2 '16 at 10:59 # Rust, 84 Bytes fn main(){loop{use std::io::Write;std::fs::File::create("a").unwrap().write(b"a");}} File::create truncates an existing file, thus ensuring that we don't run out of disk space. The used Compiler (1.9 Nightly) issues a warning about the unused result of write(...) but compiles nevertheless. # C, 92 bytes #include <stdio.h> main(){for(FILE*f=fopen("a","w+");fprintf(f," "),!fclose(f);;);return 0;} While it looks like you could save 1 byte by for(FILE*f=fopen("a","w+");fprintf(f," ")+fclose(f);;){} the problem with that loop is that + doesn't give you the guaranteed order. Or recursive - shouldn't overflow if the compiler properly implements tail recursion (f is in an explicit inner scope) # 85 bytes #include <stdio.h> main(){{FILE*f=fopen("a","w+");fprintf(f," ");fclose(f);}main();} • Hopefully the 85-byte version does not blow the stack. :P – MathuSum Mut Apr 1 '16 at 21:30 • @MathuSumMut: Easy fix: require compiling with optimizations. Tail call recursion saves the day. – Joshua Apr 3 '16 at 22:53 • There's a lot of scope for saving bytes here. See my answer for packing stuff inside the for(;;), and for shorter functions than fprintf. If you did need to include stdio.h (which you don't), you don't need a space: #include<stdio.h> – Peter Cordes May 15 '16 at 14:03 # Mathematica, 14 bytes For[,1>0,a>>a] Repeatedly writes the string "a" to a file named a in the current directory, creating it if it doesn't exist. • would it write the string "a" or the contents of the variable a? And if the latter, what would it do if that variable were not yet defined? – Michael Stern May 19 '16 at 21:53 • @MichaelStern It writes the variable a, which is undefined, so it just writes a\n. – LegionMammal978 May 20 '16 at 0:24 ## C, 40 bytes main(){for(;;)write(open("a",1)," ",1);} It will quickly run out of file descriptors, though; this can be overcome with: ## 45, 43 bytes main(f){for(f=open("a",1);;)write(f,"",1);} • Why doesn't f have a type in the second? – cat Apr 3 '16 at 2:53 • @cat In C (very K&R style) it defaults to int. – edmz Apr 3 '16 at 8:23 • gcc and clang won't compile the 2nd version. Even GNU C doesn't allow dynamic initialization of a static/global variable (a call to open() isn't a compile-time constant). Also, it will run out of disk space, because there's no lseek. Maybe try utime("a","") in the loop, which will keep updating the ctime. (You still have to open to create a file of known name). – Peter Cordes May 14 '16 at 5:59 • @PeterCordes You're right, thanks for pointing out. Fixed. – edmz May 15 '16 at 13:28 • Still doesn't satisfy the OP's requirement of not filling up the disk eventually, but maybe still worth keeping as an answer. (Unless you have an idea better than my answer's close/reopen(O_TRUNC) in a loop.) Contrary to my previous comment, updating timestamps only usually doesn't really produce actual disk I/O on Linux. Like maybe one write per 24 hours with lazytime, as I said in my answer. – Peter Cordes May 15 '16 at 13:37 # C on amd64 Linux, 36 bytes (timestamp only), 52 49 bytes (real disk activity) I hard-code the open(2) flags, so this is not portable to other ABIs. Linux on other platforms likely uses the same O_TRUNC, etc., but other POSIX OSes may not. +4 bytes to pass a correct permission arg to make sure the file is created with owner write access, see below. (This happens to work with gcc 5.2) # somewhat-portable ANSI C, 38/51 bytes (timestamp only), 52/67 bytes (real disk activity) Based on @Cat's answer, with a tip from @Jens. The first number is for implementations where an int can hold FILE *fopen()'s return value, second number if we can't do that. On Linux, heap addresses happen to be in the low 32 bits of address space, so it works even without -m32 or -mx32. (Declaring void*fopen(); is shorter than #include <stdio.h>) Timestamp metadata I/O only: main(){for(;;)close(open("a",577));} // Linux x86-64 //void*fopen(); // compile with -m32 or -mx32 or whatever, so an int holds a pointer. main(){for(;;)fclose(fopen("a","w"));} Writing a byte, actually hitting the disk on Linux 4.2.0 + XFS + lazytime: main(){for(;write(open("a",577),"",1);close(3));} write is the for-loop condition, which is fine since it always returns 1. close is the increment. // semi-portable: storing a FILE* in an int. Works on many systems main(f){for(;f=fopen("a","w");fclose(f))fputc(0,f);} // 52 bytes // Should be highly portable, except to systems that require prototypes for all functions. void*f,*fopen();main(){for(;f=fopen("a","w");fclose(f))fputc(0,f);} // 67 bytes ## Explanation of the non-portable version: The file is created with random garbage permissions. With gcc 5.2, with -O0 or -O3, it happens to include owner write permission, but this is not guaranteed. 0666 is decimal 438. A 3rd arg to open would take another 4 bytes. We're already hard-coding O_TRUNC and so on, but this could break with a different compiler or libc on the same ABI. We can't omit the 2nd arg to open, because the garbage value happens to include O_EXCL, and O_TRUNC|O_APPEND, so open fails with EINVAL. We don't need to save the return value from open(). We assume it's 3, because it always will be. Even if we start with fd 3 open, it will be closed after the first iteration. Worst-case, open keeps opening new fds until 3 is the last available file descriptor. So, up to the first 65531 write() calls could fail with EBADF, but will then work normally with every open creating fd = 3. 577 = 0x241 = O_WRONLY|O_CREAT|O_TRUNC on x86-64 Linux. Without O_TRUNC, the inode mod time and change time aren't updated, so a shorter arg isn't possible. O_TRUNC is still essential for the version that calls write to produce actual disk activity, not rewrite in place. I see some answers that open("a",1). O_CREAT is required if a doesn't already exist. O_CREAT is defined as octal 0100 (64, 0x40) on Linux. No resource leaks, so it can run forever. strace output: open("a", O_WRONLY|O_CREAT|O_TRUNC, 03777762713526650) = 3 close(3) = 0 ... repeating or open("a", O_WRONLY|O_CREAT|O_TRUNC, 01) = 3 write(3, "\0", 1) = 1 # This is the terminating 0 byte in the empty string we pass to write(2) close(3) = 0 I got the decimal value of the open flags for this ABI using strace -eraw=open on my C++ version. On a filesystem with the Linux lazytime mount option enabled, a change that only affects inode timestamps will only cause one write per 24 hours. With that mount option disabled, timestamp updating might be a viable way to wear out your SSD. (However, several other answers only do metadata I/O). ## alternatives: shorter non-working: main(){for(;;)close(write(open("a",577),"",3));} uses write's return value to pass a 3 arg to close. It saves another byte, but doesn't work with gcc -O0 or -O3 on amd64. The garbage in the 3rd arg to open is different, and doesn't include write permission. a gets created the first time, but future iterations all fail with -EACCESS. longer, working, with different system calls: main(c){for(open("a",65);pwrite(3,"",1);)sync();} rewrites a byte in-place and calls sync() to sync all filesystems system-wide. This keeps the drive light lit up. We don't care which byte, so we don't pass 4th arg to pwrite. Yay for sparse files:$ ll -s a
300K -rwx-wx--- 1 peter peter 128T May 15 11:43 a

Writing one byte at an offset of ~128TiB led to xfs using 300kiB of space to hold the extent map, I guess. Don't try this on OS X with HFS+: IIRC, HFS+ doesn't support sparse files, so it will fill the disk.

XFS is a proper 64bit filesystem, supporting individual files up to 8 exabytes. i.e. 2^63-1, the maximum value off_t can hold.

strace output:

open("a", O_WRONLY|O_CREAT, 03777711166007270) = 3
pwrite(3, "\0", 1, 139989929353760)     = 1
sync()                                  = 0
pwrite(3, "\0", 1, 139989929380071)     = 1
sync()                                  = 0
...

# Racket, 46 bytes

(do()(#f)(write-to-file'a"f"#:exists'replace))
• I was thinking of answering in Racket, but you beat me to it. :P – cat Apr 3 '16 at 2:49
• Out of curiosity, did you find a shorter answer? – Winny Apr 3 '16 at 6:20

# Factor, 73 bytes

USING: io.files io.encodings
[ 0 "a" utf8 set-file-contents ] [ t ] while

Sets the file contents to the nul byte forever.

# CBM BASIC 7.0, 9 bytes

0dS"a":rU

This program, when run, repeatedly saves itself to disk. Here's a more readable version which doesn't use BASIC keyword abbreviations:

0 dsave "a" : run
• Does it run out of cassette tape though? ;) – MathuSum Mut Apr 4 '16 at 10:18
• @MathuSumMut that would be 0 SAVE "A" : RUN – ceilingcat Feb 25 '17 at 22:39

# Python, 32 bytes

while 1:open("a","w").write("b")

Note that if run on python 3, this will produce an infinite number of warnings. Also, it will probably run out of fds if run in a non-refcounting implementation.

• Just as a note, a shorter answer exists without the write and the "w" part of the open command. – Rɪᴋᴇʀ May 14 '16 at 2:14

# Dyalog APL 15.0, 17 bytes (non-competing)

(⊢⊣⊃⎕NPUT⊢)⍣≢'A'1

Chrome currently renders U+2262 wrong. The above line should look like (⊢⊣⊃⎕NPUT⊢)⍣̸≡'A'1.

This is non-competing because version 15 has not been released yet.

Applies the function (⊢⊣⊃⎕NPUT⊢) on 'A'1 until the input is changed (i.e. never):

⊢⊣⊃⎕NPUT⊢ is a function train:

┌─┼───┐
⊢ ⊣ ┌─┼─────┐
⊃ ⎕NPUT ⊢

The rightmost returns 'A'1 unmodified; this (filename, overwrite-flag) will be the right argument to `⎕NPUT'.

'⊃' returns the first element of 'A'1 ('A'); this is the data to be written.

Then ⎕NPUT is run, and reports how many bytes were written (2 or 3 depending on OS); this becomes the right argument to the .

The leftmost again returns 'A'1 unmodified; this is the left argument to the .

ignores its right argument and returns the left argument ('A'1), this becomes the new value fed to .

Since the new value is identical to the old one, the operation is continued (forever).

# SmileBASIC, 12 bytes

SAVE"A
EXEC.
• Doesn’t it run out of cassette tape though? – MathuSum Mut Jan 1 at 10:18

# vim text editor, 10 bytes

qa:w<enter>@aq@a

8 bytes if you do not could the execution command @a