[
https://issues.apache.org/jira/browse/COMPRESS-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12689551#action_12689551
]
Christian Grobmeier commented on COMPRESS-55:
---------------------------------------------
Here is the original dcos for the mode:
The mode specifies both the regular permissions and the file type. It
consists of several bit fields as follows:
0170000 This masks the file type bits.
0140000 File type value for sockets.
0120000 File type value for symbolic links. For symbolic links,
the link body is stored as file data.
0100000 File type value for regular files.
0060000 File type value for block special devices.
0040000 File type value for directories.
0020000 File type value for character special devices.
0010000 File type value for named pipes or FIFOs.
0004000 SUID bit.
0002000 SGID bit.
0001000 Sticky bit. On some systems, this modifies the behavior
of executables and/or directories.
0000777 The lower 9 bits specify read/write/execute permissions
for world, group, and user following standard POSIX con-
ventions.
This tells me, that 0 is not correct since it is not described in the above.
But I am unsure about this. If defaulting, I would do something for regular
files and 777 or something like that
> CpioArchiveEntry ignores invalid modes
> --------------------------------------
>
> Key: COMPRESS-55
> URL: https://issues.apache.org/jira/browse/COMPRESS-55
> Project: Commons Compress
> Issue Type: Bug
> Reporter: Sebb
>
> CpioArchiveEntry has the following code:
> {code}
> default:
> // FIXME: testCpioUnarchive fails if I change the line to
> // actually throw the excpetion
> new IllegalArgumentException("Unknown mode (full mode: " + mode
> + ", masked mode: " + (mode & S_IFMT));
> }
> {code}
> As the comment says, rejecting invalid modes causes test failures.
> These appear to be caused by the code
> {bq} this.cpioEntry.setMode(0);
> in the method CpioArchiveOutputStream.finish()
> Is a mode of 0 allowed? If so, then setMode needs to allow it, otherwise the
> method call needs to change to something else.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
