In one source file there is for some reason non utf8 char. But hey this
is fs development so this kind of thing might happen.
Signed-off-by: Kari Argillander <[email protected]>
---
fs/ntfs3/frecord.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ntfs3/frecord.c b/fs/ntfs3/frecord.c
index c3121bf9c62f..e377d72477df 100644
--- a/fs/ntfs3/frecord.c
+++ b/fs/ntfs3/frecord.c
@@ -1784,7 +1784,7 @@ enum REPARSE_SIGN ni_parse_reparse(struct ntfs_inode *ni, struct ATTRIB *attr,
/*
* WOF - Windows Overlay Filter - used to compress files with lzx/xpress
* Unlike native NTFS file compression, the Windows Overlay Filter supports
- * only read operations. This means that it doesn?t need to sector-align each
+ * only read operations. This means that it doesn't need to sector-align each
* compressed chunk, so the compressed data can be packed more tightly together.
* If you open the file for writing, the Windows Overlay Filter just decompresses
* the entire file, turning it back into a plain file.
--
2.25.1
On Wed, Aug 18, 2021 at 04:06:47AM +0300, Kari Argillander wrote:
> In one source file there is for some reason non utf8 char. But hey this
> is fs development so this kind of thing might happen.
Pleaese also refomat these comments while you're at it. While going
over 80 characters is ok in exceptions for readability that is per
definition never the case for a block comment.
On Wed, Aug 18, 2021 at 07:33:00AM +0200, Christoph Hellwig wrote:
> On Wed, Aug 18, 2021 at 04:06:47AM +0300, Kari Argillander wrote:
> > In one source file there is for some reason non utf8 char. But hey this
> > is fs development so this kind of thing might happen.
>
> Pleaese also refomat these comments while you're at it. While going
> over 80 characters is ok in exceptions for readability that is per
> definition never the case for a block comment.
Yeah. Totally good option. I already did it and looks lot better.
On Wed, Aug 18, 2021 at 07:23:40AM +0200, Christoph Hellwig wrote:
> On Wed, Aug 18, 2021 at 04:06:46AM +0300, Kari Argillander wrote:
> > In ntfs3 driver there is allocation made like this ntfs_malloc().
> > Patch 2/3 will converter these to kernel ones like kmalloc(). After I
> > did this then checkpatch raise warnings about array allocations so I
> > fix these in patch 3/3.
> >
> > I also notice when I made patch that there is broken utf8 char so I
> > wanted first fix that because it raised some warning in my editor and
> > did not want to "break" patch 2/3. So patch 1/3 address that. I did
> > try to apply this and it seem to work without issues.
>
> So this mostly looks sensible, but I still haven't actually seen
> the codebase this applies to posted anywhere as far as I can tell.
Yeah that's true. Only place for mention this is here (link). I have
asked that Konstantin will send patch series v28 to mailing lists. I
will resist resending v4 before Konstantin has sended.
https://lore.kernel.org/ntfs3/[email protected]/