@Anders 0x40000 is "RecallOnOpen" and is in the lower bit position than "Pinned" (0x80000) and "Unpinned" (0x100000). I don't believe the API would display the attribute bits out of order... Do you have the license to share the test code that you called GetDetailsOf to figure out the attribute letters? That can help people to independently verify the attribute letters that were otherwise undocumented by Microsoft.
@Ander 1. Is your information accurate at all? Because attribute 0x10 should refer to "D for Directory" and should have been displayed already. Are you referring to 0x08 instead (the reserved attribute bit formerly used as Volume Label in FAT)? 2. A web search of the string "RHSDAXNTPLCOIEV" gave me this result: https://www.win7dll.info/propsys_dll.html The string was surely embedded in the file named propsys.dll. While I can confirm all other letters, the "V" letter is the only one I couldn't confirm...
Is @Anders familiar with the APIs that show the Open or Save files dialog? What I am asking is, whether we can reverse-enginner one of the Windows DLL and figure out the remaining letters without tempering with the file systems. Because years ago, I tested out almost every attribute letter that may display in Windows Explorer by creating files with such attribute using various tools (even with ntfs-3g on Linux). While I suspect the attribute column shown in the Open file dialog is same as Explorer's....
Thanks Igor. Now the information about the silent change to the (undocumented) FILE_ATTRIBUTE_STRICTLY_SEQUENTIAL constant value is new to me. And I don't have Windows Kit to verify this myself. When Microsoft introduced new NTFS file attribute bits, they have been doing this silently and I consider them being anti-competitive as well (such as "Pinned" and "Unpinned" attributes specifically designed for OneDrive before they documented them for other cloud storage solutions). I do not know anything...
Looks like the p7zip project has been abandoned, and I reported the request to the wrong place. Forwarded to here: https://sourceforge.net/p/sevenzip/bugs/2499/
NTFS file attribute letters in 7-zip
NTFS file attribute letters in 7-zip
Round values in graph drawing (instead of implicit truncate)
DragonFlyBSD PID_MAX is 999999.
Mouse-friendly functions bar for meters panel
Reword 'Type' to 'Style' for meters.
Real-time signals support (for kill command)
Mark signal tables 'const'
Optimize Strings_startWith()
Fix xStrdup debug build failure & allow Clang to use ((nonnull))
Let BarMeterMode_characters[] be const array.
Fix scrolling behavior change caused by 759caf0f
Document Alt+{h,j,k,l} and Ctrl+{A,E} into man page
Add assert and __attribute__((nonnull)) on xStrdup
Don't check if (!str) in xStrdup
Remove redundant is-null checks on free(Meter.drawData)
Reorder configure macros to avoid "missing script" warning.
Update INSTALL text from autoconf-2.69
Replace deprecated autoconf macros.
Fix macro Header_forEachColumn
Rename Meter.setValues() functions to updateValues()
BarMeterMode_draw minor code improvement
Assert (Platform_meterTypes[0]==&CPUMeter_class)
Avoid overlapping key values defined by curses (Real fix).
Revert 5c593fae4227651075cfc9445f17dad6ae0a0b47 (xCalloc)
Explicit "maxItems" property of meters
Change variable 'dot' to avoid division by reciprocal.
New macro GRAPH_HEIGHT for Graph Meter height
Introduce CLAMP macro. Unify all MIN(MAX(a,b),c) uses.
Fix function bar when moving meters.
1) I'm already aware that setting "-mmemuse=p100" effectively means removing memory limit, but I'm writing batch scripts that require some "backward compatibility" with previous version of 7-zip. The new default of "-mmemuse=p80" annoys me, as I need to override it with "-mmemuse=p100" in the new 7-zip version, on the command line (not GUI), to keep the same behavior as before. By the way, did you mean "-mmemuse=p100" instead of "-mmt=p100"? The latter looks like a typo. 2) My experiment shows that...
Since 7-zip 21.06, there is a new "-mmemuse" compression option. However, I have questions about it as I'm still confused about how it works and the manual didn't explain it clear enough. The manual says "-mmemuse" will limit the number of thread during compression or decompression so the memory usage will fit the specified limit. However... (a) If I set the number of threads ("-mmt=N") during compression, without specifying "-mmemuse", how will the number of threads be decided? Is there an easy...
Repost a valid link for the patch because the link on first post no longer works (due to Dropbox system change) https://www.dropbox.com/s/wx039kw6bmi4dkk/systester-fix-ptime-overflow.patch?dl=0 diff -r -u a/master.cpp b/master.cpp --- a/master.cpp 2012-07-09 04:41:48.000000000 +0800 +++ b/master.cpp 2013-07-16 15:58:17.105666977 +0800 @@ -38,7 +38,7 @@ unsigned long long prec = 0, bits, i = 0, n = 1; int p[MAX_THREADS], k = 0; char *pistr = NULL; - char column[111] = "", pxdigits[13] = "", ptime[13]...
Repost a valid link for the patch because the link on first post no longer works (due to Dropbox system change) https://www.dropbox.com/s/73jy3a3aj26dbez/systester-gui-64-threads.patch?dl=0 diff -r -u a/MainWindow.ui b/MainWindow.ui --- a/MainWindow.ui 2012-07-09 04:41:47.000000000 +0800 +++ b/MainWindow.ui 2013-07-17 07:19:14.556930678 +0800 @@ -2819,6 +2819,11 @@ <string>32</string> </property> </item> + <item> + <property name="text"> + <string>64</string> + </property> + </item> </widget> <widget...
Repost a valid link for the patch because the link on first post no longer works (due to Dropbox system change) https://www.dropbox.com/s/0x83b08tngi8ppf/systester-cli-args-bounds.patch?dl=0 diff -r -u a/cli/systester-cli.c b/cli/systester-cli.c --- a/cli/systester-cli.c 2012-07-09 04:41:47.000000000 +0800 +++ b/cli/systester-cli.c 2013-07-20 10:12:01.368310441 +0800 @@ -206,7 +206,11 @@ { algo = 0; arg++; - loops = determine_loops (argv[arg], algo); + if (arg < argc) + loops = determine_loops (argv[arg],...
It seems that the problem is on the '-r' option with the '.' (dot) as the filename....
In short, use: 7z a mybackup.7z * Don't use '-r'. It doesn't work the way you expected....
7-zip's file type detection should detect PE files of extensions other than EXE or...