2017-02-27 00:05:27 +00:00
|
|
|
/*
|
|
|
|
* The little filesystem
|
|
|
|
*
|
2017-10-13 01:27:33 +00:00
|
|
|
* Copyright (c) 2017 ARM Limited
|
|
|
|
*
|
|
|
|
* Licensed under the Apache License, Version 2.0 (the "License");
|
|
|
|
* you may not use this file except in compliance with the License.
|
|
|
|
* You may obtain a copy of the License at
|
|
|
|
*
|
|
|
|
* http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
*
|
|
|
|
* Unless required by applicable law or agreed to in writing, software
|
|
|
|
* distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
* See the License for the specific language governing permissions and
|
|
|
|
* limitations under the License.
|
2017-02-27 00:05:27 +00:00
|
|
|
*/
|
|
|
|
#ifndef LFS_H
|
|
|
|
#define LFS_H
|
|
|
|
|
2017-04-24 02:40:03 +00:00
|
|
|
#include <stdint.h>
|
|
|
|
#include <stdbool.h>
|
2017-02-27 00:05:27 +00:00
|
|
|
|
|
|
|
|
2018-01-26 20:26:25 +00:00
|
|
|
/// Version info ///
|
|
|
|
|
|
|
|
// Software library version
|
|
|
|
// Major (top-nibble), incremented on backwards incompatible changes
|
|
|
|
// Minor (bottom-nibble), incremented on feature additions
|
2018-04-03 13:29:28 +00:00
|
|
|
#define LFS_VERSION 0x00010004
|
2018-01-26 20:26:25 +00:00
|
|
|
#define LFS_VERSION_MAJOR (0xffff & (LFS_VERSION >> 16))
|
|
|
|
#define LFS_VERSION_MINOR (0xffff & (LFS_VERSION >> 0))
|
|
|
|
|
|
|
|
// Version of On-disk data structures
|
|
|
|
// Major (top-nibble), incremented on backwards incompatible changes
|
|
|
|
// Minor (bottom-nibble), incremented on feature additions
|
2018-04-03 13:29:28 +00:00
|
|
|
#define LFS_DISK_VERSION 0x00010002
|
2018-01-26 20:26:25 +00:00
|
|
|
#define LFS_DISK_VERSION_MAJOR (0xffff & (LFS_DISK_VERSION >> 16))
|
|
|
|
#define LFS_DISK_VERSION_MINOR (0xffff & (LFS_DISK_VERSION >> 0))
|
|
|
|
|
|
|
|
|
2017-05-15 06:26:29 +00:00
|
|
|
/// Definitions ///
|
|
|
|
|
2017-04-24 02:40:03 +00:00
|
|
|
// Type definitions
|
|
|
|
typedef uint32_t lfs_size_t;
|
|
|
|
typedef uint32_t lfs_off_t;
|
|
|
|
|
|
|
|
typedef int32_t lfs_ssize_t;
|
|
|
|
typedef int32_t lfs_soff_t;
|
|
|
|
|
|
|
|
typedef uint32_t lfs_block_t;
|
|
|
|
|
2018-04-03 13:29:28 +00:00
|
|
|
// Maximum inline file size in bytes. Large inline files require a larger
|
|
|
|
// read and prog cache, but if a file can be inline it does not need its own
|
|
|
|
// data block. LFS_ATTRS_MAX + LFS_INLINE_MAX must be <= 0xffff. Stored in
|
|
|
|
// superblock and must be respected by other littlefs drivers.
|
Added disk-backed limits on the name/attrs/inline sizes
Being a portable, microcontroller-scale embedded filesystem, littlefs is
presented with a relatively unique challenge. The amount of RAM
available is on completely different scales from machine to machine, and
what is normally a reasonable RAM assumption may break completely on an
embedded system.
A great example of this is file names. On almost every PC these days, the limit
for a file name is 255 bytes. It's a very convenient limit for a number
of reasons. However, on microcontrollers, allocating 255 bytes of RAM to
do a file search can be unreasonable.
The simplest solution (and one that has existing in littlefs for a
while), is to let this limit be redefined to a smaller value on devices
that need to save RAM. However, this presents an interesting portability
issue. If these devices are plugged into a PC with relatively infinite
RAM, nothing stops the PC from writing files with full 255-byte file
names, which can't be read on the small device.
One solution here is to store this limit on the superblock during format
time. When mounting a disk, the filesystem implementation is responsible for
checking this limit in the superblock. If it's larger than what can be
read, raise an error. If it's smaller, respect the limit on the
superblock and raise an error if the user attempts to exceed it.
In this commit, this strategy is adopted for file names, inline files,
and the size of all attributes, since these could impact the memory
consumption of the filesystem. (Recording the attribute's limit is
iffy, but is the only other arbitrary limit and could be used for disabling
support of custom attributes).
Note! This changes makes it very important to configure littlefs
correctly at format time. If littlefs is formatted on a PC without
changing the limits appropriately, it will be rejected by a smaller
device.
2018-04-01 20:36:29 +00:00
|
|
|
#ifndef LFS_INLINE_MAX
|
2018-04-03 13:28:09 +00:00
|
|
|
#define LFS_INLINE_MAX 0x3ff
|
Added disk-backed limits on the name/attrs/inline sizes
Being a portable, microcontroller-scale embedded filesystem, littlefs is
presented with a relatively unique challenge. The amount of RAM
available is on completely different scales from machine to machine, and
what is normally a reasonable RAM assumption may break completely on an
embedded system.
A great example of this is file names. On almost every PC these days, the limit
for a file name is 255 bytes. It's a very convenient limit for a number
of reasons. However, on microcontrollers, allocating 255 bytes of RAM to
do a file search can be unreasonable.
The simplest solution (and one that has existing in littlefs for a
while), is to let this limit be redefined to a smaller value on devices
that need to save RAM. However, this presents an interesting portability
issue. If these devices are plugged into a PC with relatively infinite
RAM, nothing stops the PC from writing files with full 255-byte file
names, which can't be read on the small device.
One solution here is to store this limit on the superblock during format
time. When mounting a disk, the filesystem implementation is responsible for
checking this limit in the superblock. If it's larger than what can be
read, raise an error. If it's smaller, respect the limit on the
superblock and raise an error if the user attempts to exceed it.
In this commit, this strategy is adopted for file names, inline files,
and the size of all attributes, since these could impact the memory
consumption of the filesystem. (Recording the attribute's limit is
iffy, but is the only other arbitrary limit and could be used for disabling
support of custom attributes).
Note! This changes makes it very important to configure littlefs
correctly at format time. If littlefs is formatted on a PC without
changing the limits appropriately, it will be rejected by a smaller
device.
2018-04-01 20:36:29 +00:00
|
|
|
#endif
|
|
|
|
|
2018-04-03 13:29:28 +00:00
|
|
|
// Maximum size of all attributes per file in bytes, may be redefined but a
|
|
|
|
// a smaller LFS_ATTRS_MAX has no benefit. LFS_ATTRS_MAX + LFS_INLINE_MAX
|
|
|
|
// must be <= 0xffff. Stored in superblock and must be respected by other
|
|
|
|
// littlefs drivers.
|
Added disk-backed limits on the name/attrs/inline sizes
Being a portable, microcontroller-scale embedded filesystem, littlefs is
presented with a relatively unique challenge. The amount of RAM
available is on completely different scales from machine to machine, and
what is normally a reasonable RAM assumption may break completely on an
embedded system.
A great example of this is file names. On almost every PC these days, the limit
for a file name is 255 bytes. It's a very convenient limit for a number
of reasons. However, on microcontrollers, allocating 255 bytes of RAM to
do a file search can be unreasonable.
The simplest solution (and one that has existing in littlefs for a
while), is to let this limit be redefined to a smaller value on devices
that need to save RAM. However, this presents an interesting portability
issue. If these devices are plugged into a PC with relatively infinite
RAM, nothing stops the PC from writing files with full 255-byte file
names, which can't be read on the small device.
One solution here is to store this limit on the superblock during format
time. When mounting a disk, the filesystem implementation is responsible for
checking this limit in the superblock. If it's larger than what can be
read, raise an error. If it's smaller, respect the limit on the
superblock and raise an error if the user attempts to exceed it.
In this commit, this strategy is adopted for file names, inline files,
and the size of all attributes, since these could impact the memory
consumption of the filesystem. (Recording the attribute's limit is
iffy, but is the only other arbitrary limit and could be used for disabling
support of custom attributes).
Note! This changes makes it very important to configure littlefs
correctly at format time. If littlefs is formatted on a PC without
changing the limits appropriately, it will be rejected by a smaller
device.
2018-04-01 20:36:29 +00:00
|
|
|
#ifndef LFS_ATTRS_MAX
|
2018-04-03 13:28:09 +00:00
|
|
|
#define LFS_ATTRS_MAX 0x3f
|
Added disk-backed limits on the name/attrs/inline sizes
Being a portable, microcontroller-scale embedded filesystem, littlefs is
presented with a relatively unique challenge. The amount of RAM
available is on completely different scales from machine to machine, and
what is normally a reasonable RAM assumption may break completely on an
embedded system.
A great example of this is file names. On almost every PC these days, the limit
for a file name is 255 bytes. It's a very convenient limit for a number
of reasons. However, on microcontrollers, allocating 255 bytes of RAM to
do a file search can be unreasonable.
The simplest solution (and one that has existing in littlefs for a
while), is to let this limit be redefined to a smaller value on devices
that need to save RAM. However, this presents an interesting portability
issue. If these devices are plugged into a PC with relatively infinite
RAM, nothing stops the PC from writing files with full 255-byte file
names, which can't be read on the small device.
One solution here is to store this limit on the superblock during format
time. When mounting a disk, the filesystem implementation is responsible for
checking this limit in the superblock. If it's larger than what can be
read, raise an error. If it's smaller, respect the limit on the
superblock and raise an error if the user attempts to exceed it.
In this commit, this strategy is adopted for file names, inline files,
and the size of all attributes, since these could impact the memory
consumption of the filesystem. (Recording the attribute's limit is
iffy, but is the only other arbitrary limit and could be used for disabling
support of custom attributes).
Note! This changes makes it very important to configure littlefs
correctly at format time. If littlefs is formatted on a PC without
changing the limits appropriately, it will be rejected by a smaller
device.
2018-04-01 20:36:29 +00:00
|
|
|
#endif
|
|
|
|
|
2018-04-03 13:29:28 +00:00
|
|
|
// Max name size in bytes, may be redefined to reduce the size of the
|
|
|
|
// info struct. Stored in superblock and must be respected by other
|
|
|
|
// littlefs drivers.
|
2017-04-24 02:40:03 +00:00
|
|
|
#ifndef LFS_NAME_MAX
|
2018-04-03 13:28:09 +00:00
|
|
|
#define LFS_NAME_MAX 0xff
|
2017-04-24 02:40:03 +00:00
|
|
|
#endif
|
|
|
|
|
2017-05-15 06:26:29 +00:00
|
|
|
// Possible error codes, these are negative to allow
|
|
|
|
// valid positive return values
|
2017-03-12 20:11:52 +00:00
|
|
|
enum lfs_error {
|
Added disk-backed limits on the name/attrs/inline sizes
Being a portable, microcontroller-scale embedded filesystem, littlefs is
presented with a relatively unique challenge. The amount of RAM
available is on completely different scales from machine to machine, and
what is normally a reasonable RAM assumption may break completely on an
embedded system.
A great example of this is file names. On almost every PC these days, the limit
for a file name is 255 bytes. It's a very convenient limit for a number
of reasons. However, on microcontrollers, allocating 255 bytes of RAM to
do a file search can be unreasonable.
The simplest solution (and one that has existing in littlefs for a
while), is to let this limit be redefined to a smaller value on devices
that need to save RAM. However, this presents an interesting portability
issue. If these devices are plugged into a PC with relatively infinite
RAM, nothing stops the PC from writing files with full 255-byte file
names, which can't be read on the small device.
One solution here is to store this limit on the superblock during format
time. When mounting a disk, the filesystem implementation is responsible for
checking this limit in the superblock. If it's larger than what can be
read, raise an error. If it's smaller, respect the limit on the
superblock and raise an error if the user attempts to exceed it.
In this commit, this strategy is adopted for file names, inline files,
and the size of all attributes, since these could impact the memory
consumption of the filesystem. (Recording the attribute's limit is
iffy, but is the only other arbitrary limit and could be used for disabling
support of custom attributes).
Note! This changes makes it very important to configure littlefs
correctly at format time. If littlefs is formatted on a PC without
changing the limits appropriately, it will be rejected by a smaller
device.
2018-04-01 20:36:29 +00:00
|
|
|
LFS_ERR_OK = 0, // No error
|
|
|
|
LFS_ERR_IO = -5, // Error during device operation
|
|
|
|
LFS_ERR_CORRUPT = -52, // Corrupted
|
|
|
|
LFS_ERR_NOENT = -2, // No directory entry
|
|
|
|
LFS_ERR_EXIST = -17, // Entry already exists
|
|
|
|
LFS_ERR_NOTDIR = -20, // Entry is not a dir
|
|
|
|
LFS_ERR_ISDIR = -21, // Entry is a dir
|
|
|
|
LFS_ERR_NOTEMPTY = -39, // Dir is not empty
|
|
|
|
LFS_ERR_BADF = -9, // Bad file number
|
|
|
|
LFS_ERR_INVAL = -22, // Invalid parameter
|
|
|
|
LFS_ERR_NOSPC = -28, // No space left on device
|
|
|
|
LFS_ERR_NOMEM = -12, // No more memory available
|
|
|
|
LFS_ERR_NAMETOOLONG = -36, // File name too long
|
2018-04-06 00:03:58 +00:00
|
|
|
LFS_ERR_NODATA = -61, // No data/attr available
|
|
|
|
LFS_ERR_RANGE = -34, // Result not representable
|
2017-03-13 00:41:08 +00:00
|
|
|
};
|
|
|
|
|
2017-05-15 06:26:29 +00:00
|
|
|
// File types
|
2017-03-13 00:41:08 +00:00
|
|
|
enum lfs_type {
|
2018-03-03 16:26:06 +00:00
|
|
|
// file type
|
|
|
|
LFS_TYPE_REG = 0x01,
|
|
|
|
LFS_TYPE_DIR = 0x02,
|
|
|
|
LFS_TYPE_SUPERBLOCK = 0x0e,
|
|
|
|
|
|
|
|
// on disk structure
|
|
|
|
LFS_STRUCT_CTZ = 0x10,
|
|
|
|
LFS_STRUCT_DIR = 0x20,
|
2018-03-17 15:28:14 +00:00
|
|
|
LFS_STRUCT_INLINE = 0x30,
|
2018-03-03 16:26:06 +00:00
|
|
|
LFS_STRUCT_MOVED = 0x80,
|
2017-03-12 20:11:52 +00:00
|
|
|
};
|
|
|
|
|
2017-05-15 06:26:29 +00:00
|
|
|
// File open flags
|
2017-03-20 03:00:56 +00:00
|
|
|
enum lfs_open_flags {
|
2017-04-30 16:19:37 +00:00
|
|
|
// open flags
|
2018-03-17 15:28:14 +00:00
|
|
|
LFS_O_RDONLY = 1, // Open a file as read only
|
|
|
|
LFS_O_WRONLY = 2, // Open a file as write only
|
|
|
|
LFS_O_RDWR = 3, // Open a file as read and write
|
|
|
|
LFS_O_CREAT = 0x0100, // Create a file if it does not exist
|
|
|
|
LFS_O_EXCL = 0x0200, // Fail if a file already exists
|
|
|
|
LFS_O_TRUNC = 0x0400, // Truncate the existing file to zero size
|
|
|
|
LFS_O_APPEND = 0x0800, // Move to end of file on every write
|
2017-04-30 16:19:37 +00:00
|
|
|
|
|
|
|
// internally used flags
|
Added disk-backed limits on the name/attrs/inline sizes
Being a portable, microcontroller-scale embedded filesystem, littlefs is
presented with a relatively unique challenge. The amount of RAM
available is on completely different scales from machine to machine, and
what is normally a reasonable RAM assumption may break completely on an
embedded system.
A great example of this is file names. On almost every PC these days, the limit
for a file name is 255 bytes. It's a very convenient limit for a number
of reasons. However, on microcontrollers, allocating 255 bytes of RAM to
do a file search can be unreasonable.
The simplest solution (and one that has existing in littlefs for a
while), is to let this limit be redefined to a smaller value on devices
that need to save RAM. However, this presents an interesting portability
issue. If these devices are plugged into a PC with relatively infinite
RAM, nothing stops the PC from writing files with full 255-byte file
names, which can't be read on the small device.
One solution here is to store this limit on the superblock during format
time. When mounting a disk, the filesystem implementation is responsible for
checking this limit in the superblock. If it's larger than what can be
read, raise an error. If it's smaller, respect the limit on the
superblock and raise an error if the user attempts to exceed it.
In this commit, this strategy is adopted for file names, inline files,
and the size of all attributes, since these could impact the memory
consumption of the filesystem. (Recording the attribute's limit is
iffy, but is the only other arbitrary limit and could be used for disabling
support of custom attributes).
Note! This changes makes it very important to configure littlefs
correctly at format time. If littlefs is formatted on a PC without
changing the limits appropriately, it will be rejected by a smaller
device.
2018-04-01 20:36:29 +00:00
|
|
|
LFS_F_DIRTY = 0x010000, // File does not match storage
|
|
|
|
LFS_F_WRITING = 0x020000, // File has been written since last flush
|
|
|
|
LFS_F_READING = 0x040000, // File has been read since last flush
|
|
|
|
LFS_F_ERRED = 0x080000, // An error occured during write
|
2018-03-17 15:28:14 +00:00
|
|
|
LFS_F_INLINE = 0x100000, // Currently inlined in directory entry
|
2017-03-20 03:00:56 +00:00
|
|
|
};
|
|
|
|
|
2017-05-15 06:26:29 +00:00
|
|
|
// File seek flags
|
2017-04-23 04:11:13 +00:00
|
|
|
enum lfs_whence_flags {
|
2017-05-15 06:26:29 +00:00
|
|
|
LFS_SEEK_SET = 0, // Seek relative to an absolute position
|
|
|
|
LFS_SEEK_CUR = 1, // Seek relative to the current file position
|
|
|
|
LFS_SEEK_END = 2, // Seek relative to the end of the file
|
2017-04-23 04:11:13 +00:00
|
|
|
};
|
|
|
|
|
2017-03-05 20:11:52 +00:00
|
|
|
|
2017-04-22 16:42:05 +00:00
|
|
|
// Configuration provided during initialization of the littlefs
|
2017-03-25 23:11:45 +00:00
|
|
|
struct lfs_config {
|
2017-05-15 06:26:29 +00:00
|
|
|
// Opaque user provided context that can be used to pass
|
|
|
|
// information to the block device operations
|
2017-04-22 16:42:05 +00:00
|
|
|
void *context;
|
2017-03-25 23:11:45 +00:00
|
|
|
|
2017-05-15 06:26:29 +00:00
|
|
|
// Read a region in a block. Negative error codes are propogated
|
|
|
|
// to the user.
|
2017-04-22 16:42:05 +00:00
|
|
|
int (*read)(const struct lfs_config *c, lfs_block_t block,
|
2017-04-24 04:49:21 +00:00
|
|
|
lfs_off_t off, void *buffer, lfs_size_t size);
|
2017-04-22 16:42:05 +00:00
|
|
|
|
|
|
|
// Program a region in a block. The block must have previously
|
2017-05-15 06:26:29 +00:00
|
|
|
// been erased. Negative error codes are propogated to the user.
|
2018-01-11 17:56:09 +00:00
|
|
|
// May return LFS_ERR_CORRUPT if the block should be considered bad.
|
2017-04-22 16:42:05 +00:00
|
|
|
int (*prog)(const struct lfs_config *c, lfs_block_t block,
|
2017-04-24 04:49:21 +00:00
|
|
|
lfs_off_t off, const void *buffer, lfs_size_t size);
|
2017-04-22 16:42:05 +00:00
|
|
|
|
|
|
|
// Erase a block. A block must be erased before being programmed.
|
2017-05-15 06:26:29 +00:00
|
|
|
// The state of an erased block is undefined. Negative error codes
|
|
|
|
// are propogated to the user.
|
2018-01-11 17:56:09 +00:00
|
|
|
// May return LFS_ERR_CORRUPT if the block should be considered bad.
|
2017-04-22 16:42:05 +00:00
|
|
|
int (*erase)(const struct lfs_config *c, lfs_block_t block);
|
|
|
|
|
2017-05-15 06:26:29 +00:00
|
|
|
// Sync the state of the underlying block device. Negative error codes
|
|
|
|
// are propogated to the user.
|
2017-04-22 16:42:05 +00:00
|
|
|
int (*sync)(const struct lfs_config *c);
|
|
|
|
|
2017-05-15 06:26:29 +00:00
|
|
|
// Minimum size of a block read. This determines the size of read buffers.
|
|
|
|
// This may be larger than the physical read size to improve performance
|
|
|
|
// by caching more of the block device.
|
2017-03-25 23:11:45 +00:00
|
|
|
lfs_size_t read_size;
|
2017-04-22 16:42:05 +00:00
|
|
|
|
2017-05-15 06:26:29 +00:00
|
|
|
// Minimum size of a block program. This determines the size of program
|
|
|
|
// buffers. This may be larger than the physical program size to improve
|
|
|
|
// performance by caching more of the block device.
|
2018-01-11 17:56:09 +00:00
|
|
|
// Must be a multiple of the read size.
|
2017-03-25 23:11:45 +00:00
|
|
|
lfs_size_t prog_size;
|
|
|
|
|
2017-05-15 06:26:29 +00:00
|
|
|
// Size of an erasable block. This does not impact ram consumption and
|
|
|
|
// may be larger than the physical erase size. However, this should be
|
2018-01-11 17:56:09 +00:00
|
|
|
// kept small as each file currently takes up an entire block.
|
|
|
|
// Must be a multiple of the program size.
|
2017-03-25 23:11:45 +00:00
|
|
|
lfs_size_t block_size;
|
2017-04-22 16:42:05 +00:00
|
|
|
|
|
|
|
// Number of erasable blocks on the device.
|
2017-03-25 23:11:45 +00:00
|
|
|
lfs_size_t block_count;
|
2017-04-22 18:30:40 +00:00
|
|
|
|
2017-05-15 06:26:29 +00:00
|
|
|
// Number of blocks to lookahead during block allocation. A larger
|
|
|
|
// lookahead reduces the number of passes required to allocate a block.
|
|
|
|
// The lookahead buffer requires only 1 bit per block so it can be quite
|
|
|
|
// large with little ram impact. Should be a multiple of 32.
|
2017-04-22 19:56:12 +00:00
|
|
|
lfs_size_t lookahead;
|
|
|
|
|
2017-04-22 18:30:40 +00:00
|
|
|
// Optional, statically allocated read buffer. Must be read sized.
|
|
|
|
void *read_buffer;
|
|
|
|
|
|
|
|
// Optional, statically allocated program buffer. Must be program sized.
|
|
|
|
void *prog_buffer;
|
2017-04-22 19:56:12 +00:00
|
|
|
|
2017-05-15 06:26:29 +00:00
|
|
|
// Optional, statically allocated lookahead buffer. Must be 1 bit per
|
|
|
|
// lookahead block.
|
2017-04-22 19:56:12 +00:00
|
|
|
void *lookahead_buffer;
|
2017-04-30 16:19:37 +00:00
|
|
|
|
|
|
|
// Optional, statically allocated buffer for files. Must be program sized.
|
2017-05-15 06:26:29 +00:00
|
|
|
// If enabled, only one file may be opened at a time.
|
2017-04-30 16:19:37 +00:00
|
|
|
void *file_buffer;
|
Added disk-backed limits on the name/attrs/inline sizes
Being a portable, microcontroller-scale embedded filesystem, littlefs is
presented with a relatively unique challenge. The amount of RAM
available is on completely different scales from machine to machine, and
what is normally a reasonable RAM assumption may break completely on an
embedded system.
A great example of this is file names. On almost every PC these days, the limit
for a file name is 255 bytes. It's a very convenient limit for a number
of reasons. However, on microcontrollers, allocating 255 bytes of RAM to
do a file search can be unreasonable.
The simplest solution (and one that has existing in littlefs for a
while), is to let this limit be redefined to a smaller value on devices
that need to save RAM. However, this presents an interesting portability
issue. If these devices are plugged into a PC with relatively infinite
RAM, nothing stops the PC from writing files with full 255-byte file
names, which can't be read on the small device.
One solution here is to store this limit on the superblock during format
time. When mounting a disk, the filesystem implementation is responsible for
checking this limit in the superblock. If it's larger than what can be
read, raise an error. If it's smaller, respect the limit on the
superblock and raise an error if the user attempts to exceed it.
In this commit, this strategy is adopted for file names, inline files,
and the size of all attributes, since these could impact the memory
consumption of the filesystem. (Recording the attribute's limit is
iffy, but is the only other arbitrary limit and could be used for disabling
support of custom attributes).
Note! This changes makes it very important to configure littlefs
correctly at format time. If littlefs is formatted on a PC without
changing the limits appropriately, it will be rejected by a smaller
device.
2018-04-01 20:36:29 +00:00
|
|
|
|
2018-04-03 13:29:28 +00:00
|
|
|
// Optional upper limit on inlined files in bytes. Large inline files
|
|
|
|
// require a larger read and prog cache, but if a file can be inlined it
|
|
|
|
// does not need its own data block. Must be smaller than the read size
|
|
|
|
// and prog size. Defaults to min(LFS_INLINE_MAX, read_size) when zero.
|
|
|
|
// Stored in superblock and must be respected by other littlefs drivers.
|
Added disk-backed limits on the name/attrs/inline sizes
Being a portable, microcontroller-scale embedded filesystem, littlefs is
presented with a relatively unique challenge. The amount of RAM
available is on completely different scales from machine to machine, and
what is normally a reasonable RAM assumption may break completely on an
embedded system.
A great example of this is file names. On almost every PC these days, the limit
for a file name is 255 bytes. It's a very convenient limit for a number
of reasons. However, on microcontrollers, allocating 255 bytes of RAM to
do a file search can be unreasonable.
The simplest solution (and one that has existing in littlefs for a
while), is to let this limit be redefined to a smaller value on devices
that need to save RAM. However, this presents an interesting portability
issue. If these devices are plugged into a PC with relatively infinite
RAM, nothing stops the PC from writing files with full 255-byte file
names, which can't be read on the small device.
One solution here is to store this limit on the superblock during format
time. When mounting a disk, the filesystem implementation is responsible for
checking this limit in the superblock. If it's larger than what can be
read, raise an error. If it's smaller, respect the limit on the
superblock and raise an error if the user attempts to exceed it.
In this commit, this strategy is adopted for file names, inline files,
and the size of all attributes, since these could impact the memory
consumption of the filesystem. (Recording the attribute's limit is
iffy, but is the only other arbitrary limit and could be used for disabling
support of custom attributes).
Note! This changes makes it very important to configure littlefs
correctly at format time. If littlefs is formatted on a PC without
changing the limits appropriately, it will be rejected by a smaller
device.
2018-04-01 20:36:29 +00:00
|
|
|
lfs_size_t inline_size;
|
2018-04-03 13:29:28 +00:00
|
|
|
|
|
|
|
// Optional upper limit on attributes per file in bytes. No downside for
|
|
|
|
// larger attributes size but must be less than LFS_ATTRS_MAX. Defaults to
|
|
|
|
// LFS_ATTRS_MAX when zero.Stored in superblock and must be respected by
|
|
|
|
// other littlefs drivers.
|
Added disk-backed limits on the name/attrs/inline sizes
Being a portable, microcontroller-scale embedded filesystem, littlefs is
presented with a relatively unique challenge. The amount of RAM
available is on completely different scales from machine to machine, and
what is normally a reasonable RAM assumption may break completely on an
embedded system.
A great example of this is file names. On almost every PC these days, the limit
for a file name is 255 bytes. It's a very convenient limit for a number
of reasons. However, on microcontrollers, allocating 255 bytes of RAM to
do a file search can be unreasonable.
The simplest solution (and one that has existing in littlefs for a
while), is to let this limit be redefined to a smaller value on devices
that need to save RAM. However, this presents an interesting portability
issue. If these devices are plugged into a PC with relatively infinite
RAM, nothing stops the PC from writing files with full 255-byte file
names, which can't be read on the small device.
One solution here is to store this limit on the superblock during format
time. When mounting a disk, the filesystem implementation is responsible for
checking this limit in the superblock. If it's larger than what can be
read, raise an error. If it's smaller, respect the limit on the
superblock and raise an error if the user attempts to exceed it.
In this commit, this strategy is adopted for file names, inline files,
and the size of all attributes, since these could impact the memory
consumption of the filesystem. (Recording the attribute's limit is
iffy, but is the only other arbitrary limit and could be used for disabling
support of custom attributes).
Note! This changes makes it very important to configure littlefs
correctly at format time. If littlefs is formatted on a PC without
changing the limits appropriately, it will be rejected by a smaller
device.
2018-04-01 20:36:29 +00:00
|
|
|
lfs_size_t attrs_size;
|
2018-04-03 13:29:28 +00:00
|
|
|
|
|
|
|
// Optional upper limit on length of file names in bytes. No downside for
|
|
|
|
// larger names except the size of the info struct which is controlled by
|
|
|
|
// the LFS_NAME_MAX define. Defaults to LFS_NAME_MAX when zero. Stored in
|
|
|
|
// superblock and must be respected by other littlefs drivers.
|
Added disk-backed limits on the name/attrs/inline sizes
Being a portable, microcontroller-scale embedded filesystem, littlefs is
presented with a relatively unique challenge. The amount of RAM
available is on completely different scales from machine to machine, and
what is normally a reasonable RAM assumption may break completely on an
embedded system.
A great example of this is file names. On almost every PC these days, the limit
for a file name is 255 bytes. It's a very convenient limit for a number
of reasons. However, on microcontrollers, allocating 255 bytes of RAM to
do a file search can be unreasonable.
The simplest solution (and one that has existing in littlefs for a
while), is to let this limit be redefined to a smaller value on devices
that need to save RAM. However, this presents an interesting portability
issue. If these devices are plugged into a PC with relatively infinite
RAM, nothing stops the PC from writing files with full 255-byte file
names, which can't be read on the small device.
One solution here is to store this limit on the superblock during format
time. When mounting a disk, the filesystem implementation is responsible for
checking this limit in the superblock. If it's larger than what can be
read, raise an error. If it's smaller, respect the limit on the
superblock and raise an error if the user attempts to exceed it.
In this commit, this strategy is adopted for file names, inline files,
and the size of all attributes, since these could impact the memory
consumption of the filesystem. (Recording the attribute's limit is
iffy, but is the only other arbitrary limit and could be used for disabling
support of custom attributes).
Note! This changes makes it very important to configure littlefs
correctly at format time. If littlefs is formatted on a PC without
changing the limits appropriately, it will be rejected by a smaller
device.
2018-04-01 20:36:29 +00:00
|
|
|
lfs_size_t name_size;
|
2017-03-25 23:11:45 +00:00
|
|
|
};
|
|
|
|
|
2017-05-15 06:26:29 +00:00
|
|
|
|
2017-04-22 16:42:05 +00:00
|
|
|
// File info structure
|
2017-03-25 23:11:45 +00:00
|
|
|
struct lfs_info {
|
2017-05-15 06:26:29 +00:00
|
|
|
// Type of the file, either LFS_TYPE_REG or LFS_TYPE_DIR
|
2017-03-25 23:11:45 +00:00
|
|
|
uint8_t type;
|
2017-04-22 16:42:05 +00:00
|
|
|
|
|
|
|
// Size of the file, only valid for REG files
|
2017-03-25 23:11:45 +00:00
|
|
|
lfs_size_t size;
|
2017-04-22 16:42:05 +00:00
|
|
|
|
|
|
|
// Name of the file stored as a null-terminated string
|
2017-03-25 23:11:45 +00:00
|
|
|
char name[LFS_NAME_MAX+1];
|
|
|
|
};
|
2017-03-05 20:11:52 +00:00
|
|
|
|
Added support for atomically committing custom attributes
Although it's simple and probably what most users expect, the previous
custom attributes API suffered from one problem: the inability to update
attributes atomically.
If we consider our timestamp use case, updating a file would require:
1. Update the file
2. Update the timestamp
If a power loss occurs during this sequence of updates, we could end up
with a file with an incorrect timestamp.
Is this a big deal? Probably not, but it could be a surprise only found
after a power-loss. And littlefs was developed with the _specifically_
to avoid suprises during power-loss.
The littlefs is perfectly capable of bundling multiple attribute updates
in a single directory commit. That's kind of what it was designed to do.
So all we need is a new committer opcode for list of attributes, and
then poking that list of attributes through the API.
We could provide the single-attribute functions, but don't, because the
fewer functions makes for a smaller codebase, and these are already the
more advanced functions so we can expect more from users. This also
changes semantics about what happens when we don't find an attribute,
since erroring would throw away all of the other attributes we're
processing.
To atomically commit both custom attributes and file updates, we need a
new API, lfs_file_setattr. Unfortunately the semantics are a bit more
confusing than lfs_setattr, since the attributes aren't written out
immediately.
2018-04-06 04:23:14 +00:00
|
|
|
// Custom attribute structure
|
|
|
|
struct lfs_attr {
|
|
|
|
// Type of attribute, provided by user and used to identify the attribute
|
|
|
|
uint8_t type;
|
|
|
|
|
|
|
|
// Pointer to buffer containing the attribute
|
|
|
|
void *buffer;
|
|
|
|
|
|
|
|
// Size of attribute in bytes, limited to LFS_ATTRS_MAX
|
|
|
|
lfs_size_t size;
|
|
|
|
};
|
|
|
|
|
2017-04-22 16:42:05 +00:00
|
|
|
|
2017-05-15 06:26:29 +00:00
|
|
|
/// littlefs data structures ///
|
2017-03-05 20:11:52 +00:00
|
|
|
typedef struct lfs_entry {
|
|
|
|
lfs_off_t off;
|
2018-03-16 01:58:29 +00:00
|
|
|
lfs_size_t size;
|
2017-03-05 20:11:52 +00:00
|
|
|
|
2017-03-25 21:20:31 +00:00
|
|
|
struct lfs_disk_entry {
|
2017-06-27 04:17:14 +00:00
|
|
|
uint8_t type;
|
2017-07-18 07:09:35 +00:00
|
|
|
uint8_t elen;
|
|
|
|
uint8_t alen;
|
|
|
|
uint8_t nlen;
|
2017-03-05 20:11:52 +00:00
|
|
|
union {
|
2017-03-25 21:20:31 +00:00
|
|
|
struct {
|
|
|
|
lfs_block_t head;
|
2017-03-05 20:11:52 +00:00
|
|
|
lfs_size_t size;
|
|
|
|
} file;
|
2017-03-25 21:20:31 +00:00
|
|
|
lfs_block_t dir[2];
|
2017-03-13 00:41:08 +00:00
|
|
|
} u;
|
2017-03-05 20:11:52 +00:00
|
|
|
} d;
|
|
|
|
} lfs_entry_t;
|
|
|
|
|
Added support for atomically committing custom attributes
Although it's simple and probably what most users expect, the previous
custom attributes API suffered from one problem: the inability to update
attributes atomically.
If we consider our timestamp use case, updating a file would require:
1. Update the file
2. Update the timestamp
If a power loss occurs during this sequence of updates, we could end up
with a file with an incorrect timestamp.
Is this a big deal? Probably not, but it could be a surprise only found
after a power-loss. And littlefs was developed with the _specifically_
to avoid suprises during power-loss.
The littlefs is perfectly capable of bundling multiple attribute updates
in a single directory commit. That's kind of what it was designed to do.
So all we need is a new committer opcode for list of attributes, and
then poking that list of attributes through the API.
We could provide the single-attribute functions, but don't, because the
fewer functions makes for a smaller codebase, and these are already the
more advanced functions so we can expect more from users. This also
changes semantics about what happens when we don't find an attribute,
since erroring would throw away all of the other attributes we're
processing.
To atomically commit both custom attributes and file updates, we need a
new API, lfs_file_setattr. Unfortunately the semantics are a bit more
confusing than lfs_setattr, since the attributes aren't written out
immediately.
2018-04-06 04:23:14 +00:00
|
|
|
typedef struct lfs_entry_attr {
|
|
|
|
struct lfs_disk_entry_attr {
|
2018-04-06 00:03:58 +00:00
|
|
|
uint8_t type;
|
|
|
|
uint8_t len;
|
|
|
|
} d;
|
Added support for atomically committing custom attributes
Although it's simple and probably what most users expect, the previous
custom attributes API suffered from one problem: the inability to update
attributes atomically.
If we consider our timestamp use case, updating a file would require:
1. Update the file
2. Update the timestamp
If a power loss occurs during this sequence of updates, we could end up
with a file with an incorrect timestamp.
Is this a big deal? Probably not, but it could be a surprise only found
after a power-loss. And littlefs was developed with the _specifically_
to avoid suprises during power-loss.
The littlefs is perfectly capable of bundling multiple attribute updates
in a single directory commit. That's kind of what it was designed to do.
So all we need is a new committer opcode for list of attributes, and
then poking that list of attributes through the API.
We could provide the single-attribute functions, but don't, because the
fewer functions makes for a smaller codebase, and these are already the
more advanced functions so we can expect more from users. This also
changes semantics about what happens when we don't find an attribute,
since erroring would throw away all of the other attributes we're
processing.
To atomically commit both custom attributes and file updates, we need a
new API, lfs_file_setattr. Unfortunately the semantics are a bit more
confusing than lfs_setattr, since the attributes aren't written out
immediately.
2018-04-06 04:23:14 +00:00
|
|
|
} lfs_entry_attr_t;
|
2018-04-06 00:03:58 +00:00
|
|
|
|
2017-04-30 16:19:37 +00:00
|
|
|
typedef struct lfs_cache {
|
|
|
|
lfs_block_t block;
|
|
|
|
lfs_off_t off;
|
|
|
|
uint8_t *buffer;
|
|
|
|
} lfs_cache_t;
|
|
|
|
|
2017-03-20 03:00:56 +00:00
|
|
|
typedef struct lfs_file {
|
2017-04-29 15:22:01 +00:00
|
|
|
struct lfs_file *next;
|
2017-04-24 04:39:50 +00:00
|
|
|
lfs_block_t pair[2];
|
2018-04-08 21:58:12 +00:00
|
|
|
lfs_off_t pairoff;
|
2017-04-30 16:19:37 +00:00
|
|
|
|
2017-04-24 04:39:50 +00:00
|
|
|
lfs_block_t head;
|
|
|
|
lfs_size_t size;
|
|
|
|
|
|
|
|
uint32_t flags;
|
2018-04-03 13:28:09 +00:00
|
|
|
lfs_size_t inline_size;
|
2017-04-24 04:39:50 +00:00
|
|
|
lfs_off_t pos;
|
2017-04-30 16:19:37 +00:00
|
|
|
lfs_block_t block;
|
|
|
|
lfs_off_t off;
|
|
|
|
lfs_cache_t cache;
|
2018-04-08 21:58:12 +00:00
|
|
|
|
|
|
|
const struct lfs_attr *attrs;
|
|
|
|
int attrcount;
|
2017-03-20 03:00:56 +00:00
|
|
|
} lfs_file_t;
|
|
|
|
|
2017-03-25 21:20:31 +00:00
|
|
|
typedef struct lfs_dir {
|
2017-11-22 02:53:15 +00:00
|
|
|
struct lfs_dir *next;
|
2017-03-25 21:20:31 +00:00
|
|
|
lfs_block_t pair[2];
|
|
|
|
lfs_off_t off;
|
|
|
|
|
2017-04-23 04:11:13 +00:00
|
|
|
lfs_block_t head[2];
|
|
|
|
lfs_off_t pos;
|
|
|
|
|
2017-03-25 21:20:31 +00:00
|
|
|
struct lfs_disk_dir {
|
|
|
|
uint32_t rev;
|
|
|
|
lfs_size_t size;
|
|
|
|
lfs_block_t tail[2];
|
|
|
|
} d;
|
|
|
|
} lfs_dir_t;
|
|
|
|
|
2017-03-05 20:11:52 +00:00
|
|
|
typedef struct lfs_superblock {
|
2017-03-25 21:20:31 +00:00
|
|
|
struct lfs_disk_superblock {
|
2017-05-14 17:01:45 +00:00
|
|
|
lfs_block_t root[2];
|
Added disk-backed limits on the name/attrs/inline sizes
Being a portable, microcontroller-scale embedded filesystem, littlefs is
presented with a relatively unique challenge. The amount of RAM
available is on completely different scales from machine to machine, and
what is normally a reasonable RAM assumption may break completely on an
embedded system.
A great example of this is file names. On almost every PC these days, the limit
for a file name is 255 bytes. It's a very convenient limit for a number
of reasons. However, on microcontrollers, allocating 255 bytes of RAM to
do a file search can be unreasonable.
The simplest solution (and one that has existing in littlefs for a
while), is to let this limit be redefined to a smaller value on devices
that need to save RAM. However, this presents an interesting portability
issue. If these devices are plugged into a PC with relatively infinite
RAM, nothing stops the PC from writing files with full 255-byte file
names, which can't be read on the small device.
One solution here is to store this limit on the superblock during format
time. When mounting a disk, the filesystem implementation is responsible for
checking this limit in the superblock. If it's larger than what can be
read, raise an error. If it's smaller, respect the limit on the
superblock and raise an error if the user attempts to exceed it.
In this commit, this strategy is adopted for file names, inline files,
and the size of all attributes, since these could impact the memory
consumption of the filesystem. (Recording the attribute's limit is
iffy, but is the only other arbitrary limit and could be used for disabling
support of custom attributes).
Note! This changes makes it very important to configure littlefs
correctly at format time. If littlefs is formatted on a PC without
changing the limits appropriately, it will be rejected by a smaller
device.
2018-04-01 20:36:29 +00:00
|
|
|
|
|
|
|
lfs_size_t block_size;
|
|
|
|
lfs_size_t block_count;
|
2017-06-27 04:17:14 +00:00
|
|
|
uint32_t version;
|
Added disk-backed limits on the name/attrs/inline sizes
Being a portable, microcontroller-scale embedded filesystem, littlefs is
presented with a relatively unique challenge. The amount of RAM
available is on completely different scales from machine to machine, and
what is normally a reasonable RAM assumption may break completely on an
embedded system.
A great example of this is file names. On almost every PC these days, the limit
for a file name is 255 bytes. It's a very convenient limit for a number
of reasons. However, on microcontrollers, allocating 255 bytes of RAM to
do a file search can be unreasonable.
The simplest solution (and one that has existing in littlefs for a
while), is to let this limit be redefined to a smaller value on devices
that need to save RAM. However, this presents an interesting portability
issue. If these devices are plugged into a PC with relatively infinite
RAM, nothing stops the PC from writing files with full 255-byte file
names, which can't be read on the small device.
One solution here is to store this limit on the superblock during format
time. When mounting a disk, the filesystem implementation is responsible for
checking this limit in the superblock. If it's larger than what can be
read, raise an error. If it's smaller, respect the limit on the
superblock and raise an error if the user attempts to exceed it.
In this commit, this strategy is adopted for file names, inline files,
and the size of all attributes, since these could impact the memory
consumption of the filesystem. (Recording the attribute's limit is
iffy, but is the only other arbitrary limit and could be used for disabling
support of custom attributes).
Note! This changes makes it very important to configure littlefs
correctly at format time. If littlefs is formatted on a PC without
changing the limits appropriately, it will be rejected by a smaller
device.
2018-04-01 20:36:29 +00:00
|
|
|
|
|
|
|
lfs_size_t inline_size;
|
|
|
|
lfs_size_t attrs_size;
|
|
|
|
lfs_size_t name_size;
|
2017-03-05 20:11:52 +00:00
|
|
|
} d;
|
|
|
|
} lfs_superblock_t;
|
|
|
|
|
2017-04-30 16:19:37 +00:00
|
|
|
typedef struct lfs_free {
|
|
|
|
lfs_block_t off;
|
2018-04-10 20:14:27 +00:00
|
|
|
lfs_block_t size;
|
|
|
|
lfs_block_t i;
|
2018-02-08 07:30:21 +00:00
|
|
|
lfs_block_t ack;
|
2017-09-19 02:20:33 +00:00
|
|
|
uint32_t *buffer;
|
2017-04-30 16:19:37 +00:00
|
|
|
} lfs_free_t;
|
|
|
|
|
2017-05-15 06:26:29 +00:00
|
|
|
// The littlefs type
|
2017-02-27 00:05:27 +00:00
|
|
|
typedef struct lfs {
|
2017-04-22 16:42:05 +00:00
|
|
|
const struct lfs_config *cfg;
|
2017-04-01 15:44:17 +00:00
|
|
|
|
2017-03-25 23:11:45 +00:00
|
|
|
lfs_block_t root[2];
|
2017-04-29 15:22:01 +00:00
|
|
|
lfs_file_t *files;
|
2017-11-22 02:53:15 +00:00
|
|
|
lfs_dir_t *dirs;
|
2017-02-27 00:05:27 +00:00
|
|
|
|
2017-04-30 16:19:37 +00:00
|
|
|
lfs_cache_t rcache;
|
|
|
|
lfs_cache_t pcache;
|
|
|
|
|
|
|
|
lfs_free_t free;
|
2017-09-19 02:20:33 +00:00
|
|
|
bool deorphaned;
|
Added disk-backed limits on the name/attrs/inline sizes
Being a portable, microcontroller-scale embedded filesystem, littlefs is
presented with a relatively unique challenge. The amount of RAM
available is on completely different scales from machine to machine, and
what is normally a reasonable RAM assumption may break completely on an
embedded system.
A great example of this is file names. On almost every PC these days, the limit
for a file name is 255 bytes. It's a very convenient limit for a number
of reasons. However, on microcontrollers, allocating 255 bytes of RAM to
do a file search can be unreasonable.
The simplest solution (and one that has existing in littlefs for a
while), is to let this limit be redefined to a smaller value on devices
that need to save RAM. However, this presents an interesting portability
issue. If these devices are plugged into a PC with relatively infinite
RAM, nothing stops the PC from writing files with full 255-byte file
names, which can't be read on the small device.
One solution here is to store this limit on the superblock during format
time. When mounting a disk, the filesystem implementation is responsible for
checking this limit in the superblock. If it's larger than what can be
read, raise an error. If it's smaller, respect the limit on the
superblock and raise an error if the user attempts to exceed it.
In this commit, this strategy is adopted for file names, inline files,
and the size of all attributes, since these could impact the memory
consumption of the filesystem. (Recording the attribute's limit is
iffy, but is the only other arbitrary limit and could be used for disabling
support of custom attributes).
Note! This changes makes it very important to configure littlefs
correctly at format time. If littlefs is formatted on a PC without
changing the limits appropriately, it will be rejected by a smaller
device.
2018-04-01 20:36:29 +00:00
|
|
|
|
|
|
|
lfs_size_t inline_size;
|
|
|
|
lfs_size_t attrs_size;
|
|
|
|
lfs_size_t name_size;
|
2017-02-27 00:05:27 +00:00
|
|
|
} lfs_t;
|
|
|
|
|
2017-04-22 16:42:05 +00:00
|
|
|
|
2017-05-15 06:26:29 +00:00
|
|
|
/// Filesystem functions ///
|
|
|
|
|
|
|
|
// Format a block device with the littlefs
|
|
|
|
//
|
|
|
|
// Requires a littlefs object and config struct. This clobbers the littlefs
|
|
|
|
// object, and does not leave the filesystem mounted.
|
|
|
|
//
|
|
|
|
// Returns a negative error code on failure.
|
2017-03-25 23:11:45 +00:00
|
|
|
int lfs_format(lfs_t *lfs, const struct lfs_config *config);
|
2017-05-15 06:26:29 +00:00
|
|
|
|
|
|
|
// Mounts a littlefs
|
|
|
|
//
|
|
|
|
// Requires a littlefs object and config struct. Multiple filesystems
|
|
|
|
// may be mounted simultaneously with multiple littlefs objects. Both
|
|
|
|
// lfs and config must be allocated while mounted.
|
|
|
|
//
|
|
|
|
// Returns a negative error code on failure.
|
2017-03-25 23:11:45 +00:00
|
|
|
int lfs_mount(lfs_t *lfs, const struct lfs_config *config);
|
2017-05-15 06:26:29 +00:00
|
|
|
|
|
|
|
// Unmounts a littlefs
|
|
|
|
//
|
|
|
|
// Does nothing besides releasing any allocated resources.
|
|
|
|
// Returns a negative error code on failure.
|
2017-03-25 21:20:31 +00:00
|
|
|
int lfs_unmount(lfs_t *lfs);
|
2017-02-27 00:05:27 +00:00
|
|
|
|
2017-05-15 06:26:29 +00:00
|
|
|
/// General operations ///
|
|
|
|
|
|
|
|
// Removes a file or directory
|
|
|
|
//
|
|
|
|
// If removing a directory, the directory must be empty.
|
|
|
|
// Returns a negative error code on failure.
|
2017-04-01 15:44:17 +00:00
|
|
|
int lfs_remove(lfs_t *lfs, const char *path);
|
2017-05-15 06:26:29 +00:00
|
|
|
|
|
|
|
// Rename or move a file or directory
|
|
|
|
//
|
|
|
|
// If the destination exists, it must match the source in type.
|
|
|
|
// If the destination is a directory, the directory must be empty.
|
|
|
|
//
|
|
|
|
// Returns a negative error code on failure.
|
2017-04-15 17:35:20 +00:00
|
|
|
int lfs_rename(lfs_t *lfs, const char *oldpath, const char *newpath);
|
2017-05-15 06:26:29 +00:00
|
|
|
|
|
|
|
// Find info about a file or directory
|
|
|
|
//
|
|
|
|
// Fills out the info structure, based on the specified file or directory.
|
|
|
|
// Returns a negative error code on failure.
|
2017-04-01 17:52:41 +00:00
|
|
|
int lfs_stat(lfs_t *lfs, const char *path, struct lfs_info *info);
|
2017-04-01 15:44:17 +00:00
|
|
|
|
Added support for atomically committing custom attributes
Although it's simple and probably what most users expect, the previous
custom attributes API suffered from one problem: the inability to update
attributes atomically.
If we consider our timestamp use case, updating a file would require:
1. Update the file
2. Update the timestamp
If a power loss occurs during this sequence of updates, we could end up
with a file with an incorrect timestamp.
Is this a big deal? Probably not, but it could be a surprise only found
after a power-loss. And littlefs was developed with the _specifically_
to avoid suprises during power-loss.
The littlefs is perfectly capable of bundling multiple attribute updates
in a single directory commit. That's kind of what it was designed to do.
So all we need is a new committer opcode for list of attributes, and
then poking that list of attributes through the API.
We could provide the single-attribute functions, but don't, because the
fewer functions makes for a smaller codebase, and these are already the
more advanced functions so we can expect more from users. This also
changes semantics about what happens when we don't find an attribute,
since erroring would throw away all of the other attributes we're
processing.
To atomically commit both custom attributes and file updates, we need a
new API, lfs_file_setattr. Unfortunately the semantics are a bit more
confusing than lfs_setattr, since the attributes aren't written out
immediately.
2018-04-06 04:23:14 +00:00
|
|
|
// Get custom attributes
|
2018-04-06 00:03:58 +00:00
|
|
|
//
|
Added support for atomically committing custom attributes
Although it's simple and probably what most users expect, the previous
custom attributes API suffered from one problem: the inability to update
attributes atomically.
If we consider our timestamp use case, updating a file would require:
1. Update the file
2. Update the timestamp
If a power loss occurs during this sequence of updates, we could end up
with a file with an incorrect timestamp.
Is this a big deal? Probably not, but it could be a surprise only found
after a power-loss. And littlefs was developed with the _specifically_
to avoid suprises during power-loss.
The littlefs is perfectly capable of bundling multiple attribute updates
in a single directory commit. That's kind of what it was designed to do.
So all we need is a new committer opcode for list of attributes, and
then poking that list of attributes through the API.
We could provide the single-attribute functions, but don't, because the
fewer functions makes for a smaller codebase, and these are already the
more advanced functions so we can expect more from users. This also
changes semantics about what happens when we don't find an attribute,
since erroring would throw away all of the other attributes we're
processing.
To atomically commit both custom attributes and file updates, we need a
new API, lfs_file_setattr. Unfortunately the semantics are a bit more
confusing than lfs_setattr, since the attributes aren't written out
immediately.
2018-04-06 04:23:14 +00:00
|
|
|
// Attributes are looked up based on the type id. If the stored attribute is
|
|
|
|
// smaller than the buffer, it is padded with zeros. It the stored attribute
|
|
|
|
// is larger than the buffer, LFS_ERR_RANGE is returned.
|
2018-04-06 00:03:58 +00:00
|
|
|
//
|
|
|
|
// Returns a negative error code on failure.
|
Added support for atomically committing custom attributes
Although it's simple and probably what most users expect, the previous
custom attributes API suffered from one problem: the inability to update
attributes atomically.
If we consider our timestamp use case, updating a file would require:
1. Update the file
2. Update the timestamp
If a power loss occurs during this sequence of updates, we could end up
with a file with an incorrect timestamp.
Is this a big deal? Probably not, but it could be a surprise only found
after a power-loss. And littlefs was developed with the _specifically_
to avoid suprises during power-loss.
The littlefs is perfectly capable of bundling multiple attribute updates
in a single directory commit. That's kind of what it was designed to do.
So all we need is a new committer opcode for list of attributes, and
then poking that list of attributes through the API.
We could provide the single-attribute functions, but don't, because the
fewer functions makes for a smaller codebase, and these are already the
more advanced functions so we can expect more from users. This also
changes semantics about what happens when we don't find an attribute,
since erroring would throw away all of the other attributes we're
processing.
To atomically commit both custom attributes and file updates, we need a
new API, lfs_file_setattr. Unfortunately the semantics are a bit more
confusing than lfs_setattr, since the attributes aren't written out
immediately.
2018-04-06 04:23:14 +00:00
|
|
|
int lfs_getattrs(lfs_t *lfs, const char *path,
|
|
|
|
const struct lfs_attr *attrs, int count);
|
2018-04-06 00:03:58 +00:00
|
|
|
|
Added support for atomically committing custom attributes
Although it's simple and probably what most users expect, the previous
custom attributes API suffered from one problem: the inability to update
attributes atomically.
If we consider our timestamp use case, updating a file would require:
1. Update the file
2. Update the timestamp
If a power loss occurs during this sequence of updates, we could end up
with a file with an incorrect timestamp.
Is this a big deal? Probably not, but it could be a surprise only found
after a power-loss. And littlefs was developed with the _specifically_
to avoid suprises during power-loss.
The littlefs is perfectly capable of bundling multiple attribute updates
in a single directory commit. That's kind of what it was designed to do.
So all we need is a new committer opcode for list of attributes, and
then poking that list of attributes through the API.
We could provide the single-attribute functions, but don't, because the
fewer functions makes for a smaller codebase, and these are already the
more advanced functions so we can expect more from users. This also
changes semantics about what happens when we don't find an attribute,
since erroring would throw away all of the other attributes we're
processing.
To atomically commit both custom attributes and file updates, we need a
new API, lfs_file_setattr. Unfortunately the semantics are a bit more
confusing than lfs_setattr, since the attributes aren't written out
immediately.
2018-04-06 04:23:14 +00:00
|
|
|
// Set custom attributes
|
|
|
|
//
|
|
|
|
// The array of attributes will be used to update the attributes stored on
|
|
|
|
// disk based on their type id. Unspecified attributes are left unmodified.
|
|
|
|
// Specifying an attribute with zero size deletes the attribute.
|
2018-04-06 00:03:58 +00:00
|
|
|
//
|
|
|
|
// Returns a negative error code on failure.
|
Added support for atomically committing custom attributes
Although it's simple and probably what most users expect, the previous
custom attributes API suffered from one problem: the inability to update
attributes atomically.
If we consider our timestamp use case, updating a file would require:
1. Update the file
2. Update the timestamp
If a power loss occurs during this sequence of updates, we could end up
with a file with an incorrect timestamp.
Is this a big deal? Probably not, but it could be a surprise only found
after a power-loss. And littlefs was developed with the _specifically_
to avoid suprises during power-loss.
The littlefs is perfectly capable of bundling multiple attribute updates
in a single directory commit. That's kind of what it was designed to do.
So all we need is a new committer opcode for list of attributes, and
then poking that list of attributes through the API.
We could provide the single-attribute functions, but don't, because the
fewer functions makes for a smaller codebase, and these are already the
more advanced functions so we can expect more from users. This also
changes semantics about what happens when we don't find an attribute,
since erroring would throw away all of the other attributes we're
processing.
To atomically commit both custom attributes and file updates, we need a
new API, lfs_file_setattr. Unfortunately the semantics are a bit more
confusing than lfs_setattr, since the attributes aren't written out
immediately.
2018-04-06 04:23:14 +00:00
|
|
|
int lfs_setattrs(lfs_t *lfs, const char *path,
|
|
|
|
const struct lfs_attr *attrs, int count);
|
2018-04-06 00:03:58 +00:00
|
|
|
|
2017-03-13 00:41:08 +00:00
|
|
|
|
2017-05-15 06:26:29 +00:00
|
|
|
/// File operations ///
|
|
|
|
|
|
|
|
// Open a file
|
|
|
|
//
|
|
|
|
// The mode that the file is opened in is determined
|
|
|
|
// by the flags, which are values from the enum lfs_open_flags
|
|
|
|
// that are bitwise-ored together.
|
|
|
|
//
|
|
|
|
// Returns a negative error code on failure.
|
2017-03-25 21:20:31 +00:00
|
|
|
int lfs_file_open(lfs_t *lfs, lfs_file_t *file,
|
2017-03-20 03:00:56 +00:00
|
|
|
const char *path, int flags);
|
2017-05-15 06:26:29 +00:00
|
|
|
|
|
|
|
// Close a file
|
|
|
|
//
|
|
|
|
// Any pending writes are written out to storage as though
|
|
|
|
// sync had been called and releases any allocated resources.
|
|
|
|
//
|
|
|
|
// Returns a negative error code on failure.
|
2017-03-25 21:20:31 +00:00
|
|
|
int lfs_file_close(lfs_t *lfs, lfs_file_t *file);
|
2017-05-15 06:26:29 +00:00
|
|
|
|
|
|
|
// Synchronize a file on storage
|
|
|
|
//
|
|
|
|
// Any pending writes are written out to storage.
|
|
|
|
// Returns a negative error code on failure.
|
2017-04-23 02:42:22 +00:00
|
|
|
int lfs_file_sync(lfs_t *lfs, lfs_file_t *file);
|
2017-05-15 06:26:29 +00:00
|
|
|
|
|
|
|
// Read data from file
|
|
|
|
//
|
|
|
|
// Takes a buffer and size indicating where to store the read data.
|
|
|
|
// Returns the number of bytes read, or a negative error code on failure.
|
2017-03-20 03:00:56 +00:00
|
|
|
lfs_ssize_t lfs_file_read(lfs_t *lfs, lfs_file_t *file,
|
|
|
|
void *buffer, lfs_size_t size);
|
2017-05-15 06:26:29 +00:00
|
|
|
|
|
|
|
// Write data to file
|
|
|
|
//
|
|
|
|
// Takes a buffer and size indicating the data to write. The file will not
|
|
|
|
// actually be updated on the storage until either sync or close is called.
|
|
|
|
//
|
|
|
|
// Returns the number of bytes written, or a negative error code on failure.
|
2017-04-24 02:40:03 +00:00
|
|
|
lfs_ssize_t lfs_file_write(lfs_t *lfs, lfs_file_t *file,
|
|
|
|
const void *buffer, lfs_size_t size);
|
2017-05-15 06:26:29 +00:00
|
|
|
|
|
|
|
// Change the position of the file
|
|
|
|
//
|
|
|
|
// The change in position is determined by the offset and whence flag.
|
|
|
|
// Returns the old position of the file, or a negative error code on failure.
|
2017-04-23 04:11:13 +00:00
|
|
|
lfs_soff_t lfs_file_seek(lfs_t *lfs, lfs_file_t *file,
|
|
|
|
lfs_soff_t off, int whence);
|
2017-05-15 06:26:29 +00:00
|
|
|
|
2018-01-20 23:30:40 +00:00
|
|
|
// Truncates the size of the file to the specified size
|
|
|
|
//
|
|
|
|
// Returns a negative error code on failure.
|
|
|
|
int lfs_file_truncate(lfs_t *lfs, lfs_file_t *file, lfs_off_t size);
|
|
|
|
|
2017-05-15 06:26:29 +00:00
|
|
|
// Return the position of the file
|
|
|
|
//
|
|
|
|
// Equivalent to lfs_file_seek(lfs, file, 0, LFS_SEEK_CUR)
|
|
|
|
// Returns the position of the file, or a negative error code on failure.
|
2017-04-23 04:11:13 +00:00
|
|
|
lfs_soff_t lfs_file_tell(lfs_t *lfs, lfs_file_t *file);
|
2017-05-15 06:26:29 +00:00
|
|
|
|
|
|
|
// Change the position of the file to the beginning of the file
|
|
|
|
//
|
|
|
|
// Equivalent to lfs_file_seek(lfs, file, 0, LFS_SEEK_CUR)
|
|
|
|
// Returns a negative error code on failure.
|
2017-04-23 04:11:13 +00:00
|
|
|
int lfs_file_rewind(lfs_t *lfs, lfs_file_t *file);
|
2017-05-15 06:26:29 +00:00
|
|
|
|
|
|
|
// Return the size of the file
|
|
|
|
//
|
|
|
|
// Similar to lfs_file_seek(lfs, file, 0, LFS_SEEK_END)
|
|
|
|
// Returns the size of the file, or a negative error code on failure.
|
2017-04-24 02:40:03 +00:00
|
|
|
lfs_soff_t lfs_file_size(lfs_t *lfs, lfs_file_t *file);
|
2017-03-13 00:41:08 +00:00
|
|
|
|
Added support for atomically committing custom attributes
Although it's simple and probably what most users expect, the previous
custom attributes API suffered from one problem: the inability to update
attributes atomically.
If we consider our timestamp use case, updating a file would require:
1. Update the file
2. Update the timestamp
If a power loss occurs during this sequence of updates, we could end up
with a file with an incorrect timestamp.
Is this a big deal? Probably not, but it could be a surprise only found
after a power-loss. And littlefs was developed with the _specifically_
to avoid suprises during power-loss.
The littlefs is perfectly capable of bundling multiple attribute updates
in a single directory commit. That's kind of what it was designed to do.
So all we need is a new committer opcode for list of attributes, and
then poking that list of attributes through the API.
We could provide the single-attribute functions, but don't, because the
fewer functions makes for a smaller codebase, and these are already the
more advanced functions so we can expect more from users. This also
changes semantics about what happens when we don't find an attribute,
since erroring would throw away all of the other attributes we're
processing.
To atomically commit both custom attributes and file updates, we need a
new API, lfs_file_setattr. Unfortunately the semantics are a bit more
confusing than lfs_setattr, since the attributes aren't written out
immediately.
2018-04-06 04:23:14 +00:00
|
|
|
// Get custom attributes attached to a file
|
|
|
|
//
|
|
|
|
// Attributes are looked up based on the type id. If the stored attribute is
|
|
|
|
// smaller than the buffer, it is padded with zeros. It the stored attribute
|
|
|
|
// is larger than the buffer, LFS_ERR_RANGE is returned.
|
|
|
|
//
|
|
|
|
// Returns a negative error code on failure.
|
|
|
|
int lfs_file_getattrs(lfs_t *lfs, lfs_file_t *file,
|
|
|
|
const struct lfs_attr *attrs, int count);
|
|
|
|
|
|
|
|
// Set custom attributes on a file
|
|
|
|
//
|
|
|
|
// The array of attributes will be used to update the attributes stored on
|
|
|
|
// disk based on their type id. Unspecified attributes are left unmodified.
|
|
|
|
// Specifying an attribute with zero size deletes the attribute.
|
|
|
|
//
|
|
|
|
// Note: Attributes are not written out until a call to lfs_file_sync
|
|
|
|
// or lfs_file_close and must be allocated until the file is closed or
|
|
|
|
// lfs_file_setattrs is called with a count of zero.
|
|
|
|
//
|
|
|
|
// Returns a negative error code on failure.
|
|
|
|
int lfs_file_setattrs(lfs_t *lfs, lfs_file_t *file,
|
|
|
|
const struct lfs_attr *attrs, int count);
|
|
|
|
|
2017-05-15 06:26:29 +00:00
|
|
|
|
|
|
|
/// Directory operations ///
|
|
|
|
|
|
|
|
// Create a directory
|
|
|
|
//
|
|
|
|
// Returns a negative error code on failure.
|
|
|
|
int lfs_mkdir(lfs_t *lfs, const char *path);
|
|
|
|
|
|
|
|
// Open a directory
|
|
|
|
//
|
|
|
|
// Once open a directory can be used with read to iterate over files.
|
|
|
|
// Returns a negative error code on failure.
|
|
|
|
int lfs_dir_open(lfs_t *lfs, lfs_dir_t *dir, const char *path);
|
|
|
|
|
|
|
|
// Close a directory
|
|
|
|
//
|
|
|
|
// Releases any allocated resources.
|
|
|
|
// Returns a negative error code on failure.
|
|
|
|
int lfs_dir_close(lfs_t *lfs, lfs_dir_t *dir);
|
|
|
|
|
|
|
|
// Read an entry in the directory
|
|
|
|
//
|
|
|
|
// Fills out the info structure, based on the specified file or directory.
|
|
|
|
// Returns a negative error code on failure.
|
|
|
|
int lfs_dir_read(lfs_t *lfs, lfs_dir_t *dir, struct lfs_info *info);
|
|
|
|
|
|
|
|
// Change the position of the directory
|
|
|
|
//
|
|
|
|
// The new off must be a value previous returned from tell and specifies
|
|
|
|
// an absolute offset in the directory seek.
|
|
|
|
//
|
|
|
|
// Returns a negative error code on failure.
|
|
|
|
int lfs_dir_seek(lfs_t *lfs, lfs_dir_t *dir, lfs_off_t off);
|
|
|
|
|
|
|
|
// Return the position of the directory
|
|
|
|
//
|
|
|
|
// The returned offset is only meant to be consumed by seek and may not make
|
|
|
|
// sense, but does indicate the current position in the directory iteration.
|
|
|
|
//
|
|
|
|
// Returns the position of the directory, or a negative error code on failure.
|
|
|
|
lfs_soff_t lfs_dir_tell(lfs_t *lfs, lfs_dir_t *dir);
|
|
|
|
|
|
|
|
// Change the position of the directory to the beginning of the directory
|
|
|
|
//
|
|
|
|
// Returns a negative error code on failure.
|
|
|
|
int lfs_dir_rewind(lfs_t *lfs, lfs_dir_t *dir);
|
|
|
|
|
|
|
|
|
Added support for atomically committing custom attributes
Although it's simple and probably what most users expect, the previous
custom attributes API suffered from one problem: the inability to update
attributes atomically.
If we consider our timestamp use case, updating a file would require:
1. Update the file
2. Update the timestamp
If a power loss occurs during this sequence of updates, we could end up
with a file with an incorrect timestamp.
Is this a big deal? Probably not, but it could be a surprise only found
after a power-loss. And littlefs was developed with the _specifically_
to avoid suprises during power-loss.
The littlefs is perfectly capable of bundling multiple attribute updates
in a single directory commit. That's kind of what it was designed to do.
So all we need is a new committer opcode for list of attributes, and
then poking that list of attributes through the API.
We could provide the single-attribute functions, but don't, because the
fewer functions makes for a smaller codebase, and these are already the
more advanced functions so we can expect more from users. This also
changes semantics about what happens when we don't find an attribute,
since erroring would throw away all of the other attributes we're
processing.
To atomically commit both custom attributes and file updates, we need a
new API, lfs_file_setattr. Unfortunately the semantics are a bit more
confusing than lfs_setattr, since the attributes aren't written out
immediately.
2018-04-06 04:23:14 +00:00
|
|
|
/// Filesystem filesystem operations ///
|
|
|
|
|
|
|
|
// Get custom attributes on the filesystem
|
|
|
|
//
|
|
|
|
// Attributes are looked up based on the type id. If the stored attribute is
|
|
|
|
// smaller than the buffer, it is padded with zeros. It the stored attribute
|
|
|
|
// is larger than the buffer, LFS_ERR_RANGE is returned.
|
|
|
|
//
|
|
|
|
// Returns a negative error code on failure.
|
|
|
|
int lfs_fs_getattrs(lfs_t *lfs, const struct lfs_attr *attrs, int count);
|
|
|
|
|
|
|
|
// Set custom attributes on the filesystem
|
|
|
|
//
|
|
|
|
// The array of attributes will be used to update the attributes stored on
|
|
|
|
// disk based on their type id. Unspecified attributes are left unmodified.
|
|
|
|
// Specifying an attribute with zero size deletes the attribute.
|
|
|
|
//
|
|
|
|
// Note: Filesystem level attributes are not available for wear-leveling
|
|
|
|
//
|
|
|
|
// Returns a negative error code on failure.
|
|
|
|
int lfs_fs_setattrs(lfs_t *lfs, const struct lfs_attr *attrs, int count);
|
|
|
|
|
|
|
|
|
2017-05-15 06:26:29 +00:00
|
|
|
/// Miscellaneous littlefs specific operations ///
|
|
|
|
|
|
|
|
// Traverse through all blocks in use by the filesystem
|
|
|
|
//
|
|
|
|
// The provided callback will be called with each block address that is
|
|
|
|
// currently in use by the filesystem. This can be used to determine which
|
|
|
|
// blocks are in use or how much of the storage is available.
|
|
|
|
//
|
|
|
|
// Returns a negative error code on failure.
|
2017-04-14 22:33:36 +00:00
|
|
|
int lfs_traverse(lfs_t *lfs, int (*cb)(void*, lfs_block_t), void *data);
|
2017-05-15 06:26:29 +00:00
|
|
|
|
|
|
|
// Prunes any recoverable errors that may have occured in the filesystem
|
|
|
|
//
|
|
|
|
// Not needed to be called by user unless an operation is interrupted
|
|
|
|
// but the filesystem is still mounted. This is already called on first
|
|
|
|
// allocation.
|
|
|
|
//
|
|
|
|
// Returns a negative error code on failure.
|
2017-05-14 17:01:45 +00:00
|
|
|
int lfs_deorphan(lfs_t *lfs);
|
2017-04-14 22:33:36 +00:00
|
|
|
|
2017-04-22 16:42:05 +00:00
|
|
|
|
2017-02-27 00:05:27 +00:00
|
|
|
#endif
|