Messages in this thread | | | Subject | Re: [PATCH] udf: reduce leakage of blocks related to named streams | From | Steve Magnani <> | Date | Fri, 9 Aug 2019 09:10:24 -0500 |
| |
Jan -
Thanks for the feedback.
On 8/9/19 8:05 AM, Jan Kara wrote: > On Wed 07-08-19 08:32:58, Steven J. Magnani wrote: >> From: Steve Magnani <steve@digidescorp.com> >> >> Windows is capable of creating UDF files having named streams. >> One example is the "Zone.Identifier" stream attached automatically >> to files downloaded from a network. See: >> https://msdn.microsoft.com/en-us/library/dn392609.aspx >> >> Modification of a file having one or more named streams in Linux causes >> the stream directory to become detached from the file, essentially leaking >> all blocks pertaining to the file's streams. Worse, an attempt to delete >> the file causes its directory entry (FID) to be deleted, but because the >> driver believes that a hard link to the file remains, the Extended File >> Entry (EFE) and all extents of the file itself remain allocated. Since >> there is no hard link, after the FID has been deleted all of these blocks >> are unreachable (leaked). >> >> ... >> >> For this case, this partial solution reduces the number of blocks leaked >> during file deletion to just one (the EFE containing the stream data). >> >> > Thanks for the patch! I was thinking about this and rather than this > partial fix, I'd prefer to fail the last unlink of an inode with > a named-stream directory with EOPNOTSUPP. Later we can properly handle this > and walk the named-stream directory and remove all associated EFEs for the > named streams. After all named-stream directories are restricted to not > have any subdirectories, hardlinks, or anything similarly fancy so the walk > should not be *that* hard to implement. > Maybe not but it's more work than I am able to take on anytime soon. Absent a complete solution, how to handle this is a judgement call. Since Windows seems to attach a Zone.Identifier stream to _all_ files downloaded from a network, and since interchange between Windows and Linux via USB Mass Storage is a somewhat common (or at least desirable) use case for UDF, this issue seemed fairly serious from a user perspective. Leaking all the blocks of a file on delete is pretty bad. Leaking a single block is still bad, but much less so. One could argue that prohibiting deletion of files with named streams is nearly as bad as leaking all the blocks - in both cases, within Linux, none of the file's blocks can be reused. That's pretty limiting for users. It's too limiting for my use cases.
------------------------------------------------------------------------ Steven J. Magnani "I claim this network for MARS! www.digidescorp.com Earthling, return my space modulator!"
#include <standard.disclaimer>
| |