Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

My company has hosted FTP, and we are currently over our disk quota. I need a way of finding out which folders on the FTP are the biggest culprits, so I can see if I can get rid of anything. I don't have time to visit every folder looking at filesizes, but I was wondering if there was any software solution for this.

share|improve this question
    
Do you have SSH access to a shell on the server? –  robertc Aug 13 '09 at 10:18
    
No. –  Skilldrick Aug 13 '09 at 10:20
add comment

3 Answers

It depends on the FTP server software being used at the other end.

Some unix-a-like FTP daemons support retrieving a recursive directory listing (you'd get output similar to that from ls -lR), which you could manually scan to look for large files, but this is not a standard feature. You could try just issuing the command ls -lR directly and see what you get back, or LIST -lR.

If you have SSH access to the remote end as well as FTP, then you could use the du command to list directory sizes. If you are in the top level directory of the area you have a fixed quota for, then issuing du will do the trick or du -h if you prefer the output in Gb/Mb/Kb instead of bytes. Also du -sc * (or du -shc *) will list a summary for the current directory, without separate readings for all sub-directories.

Edit: I forgot to add above, that if you login via a command-line FTP client (or can see the full activity log in any GUI based client you use) the server may identify itself (i.e. the actual FTP daemon used and its version number). If so, you can use this information to locate the documentation for the server and see if it does officially support a recursive directory listing.

One other suggestion: if you can afford to waste bandwidth more than you can afford to spend time on the search for big files, you could du a recursive download of the FTP location to your local machine and analyse the file/directory sizes there using local tools.

A much better option, but probably only available if you are running Linux, is to use a FUSE based FTP filesystem (http://sourceforge.net/apps/mediawiki/fuse/index.php?title=NetworkFileSystems#CurlFtpFS) - this would allow you to use commands like du and find directly on the FTP filesystem from your local machine.

share|improve this answer
add comment
up vote 3 down vote accepted

These were useful answers, but didn't really help in this case.

In the end, I was able to do a search using Filezilla for files over a certain size, and display them in size order. This wasn't able to give me the largest directories, but it did give me the largest files, which is arguably more useful.

Thanks anyway!

share|improve this answer
add comment

If you can log in to the FTP server (and it's running something sufficiently unix-like), you can use either find or du to locate the space users.

To recursively find large files with du, you can use "du -s *" (or "du -s * | sort -n") to find the largest directories and files, then recursively work your way down the tree, concentrating on these.

To find large files using find, use "find . -type f -size +nM -print" (this should give you a list of all files larger than n MB). With a careful tuning of n, it should give you exactly the large files.

If you don't have shell access, you'll have to log in to the hosted FTP site and use the FTP "dir" command to get this information. Off-hand, I don't know of anything ready-made to recurse through and find large files, but there are several programs out there for FTP mirroring and maybe one of those would allow you to pull a local copy of the site so you can do the shell-based discovery there.

share|improve this answer
    
OP doesn't have shell access –  David Rickman Aug 13 '09 at 10:44
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.