Reduces memory by a tiny bit. Arguably we never needed tombstones
because entries are never removed, so there shouldn't be any performance
hit there. We don't even need a 'used' flag either, considering that can
be represented by a NULL value, but I'm not really up for
implementing/modifying my own hash table.
ref: https://attractivechaos.wordpress.com/2019/12/28/deletion-from-hash-tables-without-tombstones/
This is a best-effort approach to save ncdu state when memory is low.
There's likely allocation in libraries that isn't being checked
(ncurses, printf).
Fixes#132 (it actually doesn't, that needs a 64bit static binary too,
but I'll get to that)
This allocation is currently leaked, but as long as we don't allocate
new ones for each refresh, that shouldn't be much of an issue.
(cherry picked from commit 9dc2d32a8f)
This adds an 'm' command to show the latest modified time of all files
in a directory. The 'M' command allows for ascending and descending
mtime sorting. These are only enabled with the -e flag and overload
the dir_ext mtime field.
I had taken care to not sort empty directories during dirlist_open(),
but forgot that manual user actions can still cause dirlist_set_sort()
to be called, which does not handle empty directories.
Reported by Alex Wilson.
'char' may be unsigned on some architectures, which will cause the
"overflow check" on decrement to fail.
This would at most result in a confusing UI issue where no confirmation
option appears to be selected.
Unfortunately, there wasn't a single bit free in struct dir.flags, so I
had to increase its size to 16 bit. This commit is just the initial
preparation, there's still a few things to do:
- Add "extended information" cli flag to enable/disable this
functionality.
- Export and import extended information when requested
- Do something with the data.
I also did a few memory measurements on a file list with 12769842 items:
before this commit: 1.239 GiB
without extended info: 1.318 GiB
with extended info: 1.698 GiB
It's surprising what adding a single byte to a struct can do to the
memory usage. :(
Fixes https://dev.yorhel.nl/ncdu/bug/103
I don't think a stack overflow as a result of recursion is exploitable
on a modern system. It should just result in an unfortunate write to a
page that is not writable, followed by a crash.
I've decided not to use ls-like file name coloring for now, instead just
coloring the difference between a (regular) file and a dir.
Still looking for a good color scheme for light backgrounds.
This should fix https://dev.yorhel.nl/ncdu/bug/99 - with the downside
that this requires a C99 compiler.
I also replaced all occurrences of static allocation of struct dir with
use dynamic allocation, because I wasn't really sure if static
allocation of flexible structs is allowed. In the case of dirlist.c the
dynamic allocation is likely required anyway, because it does store a
few bytes in the name field.
TODO:
- Add (ls-like) colors to the actual file names
-> Implement full $LS_COLORS handling or something simple and custom?
- Test on a white/black terminal, and provide an alternate color scheme
if necessary.
- Make colors opt-in?
Check if the environment variable NCDU_SHELL is defined before the SHELL
variable is checked. This makes it possible to specify a program to
execute when 'b' is pressed. Setting SHELL to for example "mc" (Midnight
Commander) didn't work because mc already uses SHELL to execute
commands.
The check for the system() exit status is slightly problematic, because
bash returns the status code of the last command it executed. I've set
it to only check for status code 127 now (command not found) in order to
at least provide a message when the $SHELL command can't be found. This
error can still be triggered when executing a nonexistant command within
the shell and then exiting.
Key 'b' in the browse window spawns a shell in the current directoy.
We first check the $SHELL environment variable of the user for the preferred
shell interpreter. If it's not set, we fall back to the compile time
configured default shell (usually /bin/bash).
Signed-off-by: Thomas Jarosch <thomas.jarosch@intra2net.com>
Turns out that being able to open an empty directory actually has its
uses:
- If you delete the last file in a directory, you now won't be directed
to the parent directory anymore. This allows keeping 'd' pressed
without worrying that you'll delete stuff outside of the current dir.
(This is the primary motivation for doing this)
- You can now scan and later refresh an empty directory, as suggested by
#2 in http://dev.yorhel.nl/ncdu/bug/15
Tiny bug fix: The size of an excluded directory entry itself should not
be counted, either. This is consistent with what you'd expect: A cache
directory with thousands of files can easily take up several megabytes
for the dir entry - but from the perspective of a backup system that
recognizes cache dirs - the dir is empty, and therefore shouldn't take
any extra space at all.
Use a macro instead of the global constant `cachedir_tag_signature`.
Use `memcmp` instead of `strncmp`.
Add `has_cachedir_tag` to exclude.h.
(See http://dev.yorhel.nl/ncdu/bug/30)
I realized that I used addparentstats() with negative values when
removing stuff, so it had to be done this way (without rewriting
everything). It's a simple solution, anyway.
This mostly avoids the issue of getting negative sizes. It's still
possible to get a negative size after refresh or deletion, I'll get to
that in a bit.
They should now be able to cope with file sizes in the full (positive)
range of a signed integer, i.e. 0 bytes to 8 EiB minus one byte. The
size calculation of directories, however, may still overflow and cause
negative integers to be passed around. That should be fixed.
It's kinda annoying how you need to confirm the messages. I'd prefer
having some status bar where messages are automatically removed after a
short timeout or something. But that's more work, and for the few
cases where feedback is necessary this'll work fine, too.
Some measurements importing a gzip-compressed file (zcat .. | ncdu -f -)
containing a bit under 6 million items and a few choices of how often to
call input_handle():
Called on every item:
real 0m13.745s
user 0m12.576s
sys 0m4.566s
Called on every 8 items:
real 0m7.932s
user 0m9.636s
sys 0m1.623s
Called on every 16 items:
real 0m7.559s
user 0m9.553s
sys 0m1.323s
Called on every 32 items:
real 0m7.279s
user 0m9.353s
sys 0m1.277s
Called on every 64 items:
real 0m7.166s
user 0m9.389s
sys 0m1.117s
Called on every 256 items:
real 0m7.073s
user 0m9.439s
sys 0m1.027s
32 seemed like a good compromise.
- errors in item() didn't propagate properly
- empty [] and {} values weren't allowed
- fractional numbers weren't allowed
- parsing of escaped characters didn't ensure that enough data was in
the buffer
- E() didn't propagate errors properly in all cases
I'll do some more testing later on, but the current code seems to be
working quite well already.
This is a quick hack to fix http://dev.yorhel.nl/ncdu/bug/18.
path_real() is both rather unreadable, fragile, hard to maintain and a
bit inefficient. It wouldn't be too surprising if I introduced a new bug
with this commit...
*makes a note to do a proper rewrite of that code later on*
!WARNING! The export option is experimental, and the file format is not
final. I make no promise that a future version of ncdu will be able to
read the current format. There's also quite a few TODO's left.
There used to be four bytes of padding in the struct on systems with
32bit pointers. Moving the pointers down so that they are in between the
64bit and 32bit fields means that there'll never be any padding.
There may, however, be some extra padding at the end of the struct to
make the size a multiple of 8. Since we use the name field as a sort of
"flexible array member", we don't particularly care about that padding
and just want to allocate enough memory to hold the struct and the name
field. offsetof() allows us to do that without relying on compiler
support for flexible array members.
POSIX defines ino_t to be of an unsigned integer type, and searching
around the net didn't tell me of any definitions conflicting that. So
every ino_t can be represented in an uint64_t. (Assuming that is the
largest integer type in use for an inode number, but I'm sure that
assumption will hold for a while)
(dev_t, on the other hand, is a bit messier. Still figuring out what to
do with that.)
2 billion files should be enough for everyone. You probably won't have
enough memory to scan such a filesystem. int is a better choice than
long, as sizeof(int) is 4 on pretty much any system where ncdu runs.
This allows scanning stuff without initializing ncurses. Not too useful
at this point since ncdu will switch to an ncurses environment when it's
done anyway, but this will become more useful when the export-to-file
feature has been implemented.
