Audible Manager

[dse]

@Weng said in Audible Manager:

Convention, however, is not to display shares ending in $. Samba ignores this convention because it's kind of dumb.

yeah! why the fuck do you want to hide your Secret$, unless you want to hide your tax returns like Trump, just delete the damn thing like Hillary would

[dkf]

@accalia said in Audible Manager:

teeeeeechnically correct

Some filesystems do, but you see them more commonly on other Unixes like OSX.

[Steve_The_Cynic]

@accalia said in Audible Manager:

@Steve_The_Cynic said in Audible Manager:

@accalia said in Audible Manager:

@Steve_The_Cynic said in Audible Manager:

Does it respect the FAT/FAT32 hidden flag?

it's Capable of doing so, it reads the XATTRS correctly, it can even manipulate them with the right utility. but ls and other command line tools do not respect them.

IIRC the file explorer used by KDE does respect hidden XATTRS if you set the right option but it's been too long since i used KDE i'm not 100% on that

The hidden flag in FAT/FAT32 isn't an XATTR. It's a single bit in the directory entry. Does the Linux kernel translate that into an XATTR?

-shrug- hell if i know. i would assume it does if for no other reason than to present a standardized interface to userspace and leave the nasty mapping of concepts to the file system driver.

could be wrong though. can't be assed to find documentation proving me either write or wrong..

Hmm. I looked a bit. A small bit. Looks like they ("hidden", "archive" and "system" bits) aren't accessible directly via the normal Linux APIs. They can be manipulated using the mtools package.

Hidden: what the name says. Well, sort of, maybe. Windows tends to hide them, but might not.
System: normally set only on, well, system files (approximately: the MS-DOS kernel files, and not really all that much on Windows). Windows tends to hide them.
Archive: set whenever a file is written, cleared by backup utilities. Useful for automatic incremental backup systems.

[dkf]

@Steve_The_Cynic said in Audible Manager:

System: normally set only on, well, system files (approximately: the MS-DOS kernel files, and not really all that much on Windows). Windows tends to hide them.

I think it's set on the pagefile and maybe the kernel image. Perhaps a few other basic bits like that.

[dcon]

@Steve_The_Cynic said in Audible Manager:

All proper(1) Win32 file APIs

The APIs might. But the odds are strong the programmer is using TCHAR buffer[MAX_PATH]

Win32s

STOP IT. I stopped having those nightmares years ago. NOW YOU'VE DONE IT!

[dse]

@dcon said in Audible Manager:

@Steve_The_Cynic said in Audible Manager:

All proper(1) Win32 file APIs

The APIs might. But the odds are strong the programmer is using TCHAR buffer[MAX_PATH]

Win32s

STOP IT. I stopped having those nightmares years ago. NOW YOU'VE DONE IT!

LPTCSTR* buffer[MAX_PAIN];

[Luhmann]

@dse said in Audible Manager:

MAX_PAIN

[anonymous234]

@Steve_The_Cynic Try copying your \username\AppData, or C:\Windows\ folders somewhere and deleting them. You'll most likely get a complaint that some file path is too long to copy/delete and it's definitely not 32k characters long.

If Explorer imposes some limit, I think it's fair to say it's a native Windows limit.

[Steve_The_Cynic]

@dcon said in Audible Manager:

@Steve_The_Cynic said in Audible Manager:

All proper(1) Win32 file APIs

The APIs might. But the odds are strong the programmer is using TCHAR buffer[MAX_PATH]

That's why I worded it like that, of course. If you don't use the backslash-backslash-dot-backslash prefix and wide characters, you pay the price of path length, but gain convenience for "ordinary" uses.

My experience with this format arises out of a one-way file-sync utility I wrote(1), where it was trivial to end up generating over-MAX_PATH paths along the way.

(1) I tried rsync compiled for cygwin. It was monstrously slow. My tool uses CopyFileExW to actually copy files, which goes like greased owl shit, relatively speaking. (e.g. 80MB/sec between two USB-3.0 hard disks, where I'd guess the limit is the actual disk-read and disk-write rate)

@anonymous234 said in Audible Manager:

@Steve_The_Cynic Try copying your \username\AppData, or C:\Windows\ folders somewhere and deleting them. You'll most likely get a complaint that some file path is too long to copy/delete and it's definitely not 32k characters long.

If Explorer imposes some limit, I think it's fair to say it's a native Windows limit.

It might be fair to say that, but it's also wrong. The true native Windows limit is 32767 characters. The convenience versions of the file APIs impose a smaller limit, but that limit is NOT a native limit in the sense most people would understand.

I'd guess that Explorer is trying to prevent "weak"(2) software from experiencing problems accessing the files.

(2) Calling them "weak" is unfair, partly because if you use the "A" versions of the file APIs you can't use the special syntax at all, and partly because using it is a bit onerous even if you use the "W" versions of the APIs.

EDIT: I guess what I'm saying about the native limit thing is that the "native" Windows APIs have a 32K-1 limit, and that the Win32 subsystem adds a convenience layer over the top that makes them easier to use. The backslash-backslash-dot-backslash prefix is an instruction to CreateFileW and friends to bypass the convenience layer and go directly to the native APIs, but it leaves you exposed to the more onerous rules of those APIs.

[anonymous234]

@Steve_The_Cynic How many "Windows APIs" are there? I've never touched that stuff (and I probably never will) but it all just seems like a big mess to me.

[Bulb]

@Steve_The_Cynic said in Audible Manager:

cygwin. It was monstrously slow

Yep. Cygwin's a disaster, because the windows API provides slightly different information that the POSIX one and Cygwin goes way out of its way to provide compatibility.

@Steve_The_Cynic said in Audible Manager:

like greased owl shit, relatively speaking

Only relatively though. Windows still suck big time when it comes to working with filesystem, especially listing directories and getting and manipulating file attributes.

@Steve_The_Cynic said in Audible Manager:

I guess what I'm saying about the native limit thing is that the "native" Windows APIs have a 32K-1 limit, and that the Win32 subsystem adds a convenience layer over the top that makes them easier to use.

And AFAICT, modern Cygwin and MSys use the lower layer. Which means you can have file called "nul" or "con" and can have long paths etc. And then you can't manipulate these files in expolorer nor raw cmd.exe because that still uses the Win32 layer.

[Steve_The_Cynic]

@Bulb said in Audible Manager:

@Steve_The_Cynic said in Audible Manager:

cygwin. It was monstrously slow

Yep. Cygwin's a disaster, because the windows API provides slightly different information that the POSIX one and Cygwin goes way out of its way to provide compatibility.

Well, I was referring to just the actual copying part on large files e.g. the 9GB backups of my Perforce repository. Rsync-on-cygwin was getting a few hundred KB/sec rather than the 80MB/sec I've seen from CopyFileExW(), with a callback posting memory-allocating messages back to a GUI, too.

@Bulb said in Audible Manager:

@Steve_The_Cynic said in Audible Manager:

like greased owl shit, relatively speaking

Only relatively though. Windows still suck big time when it comes to working with filesystem, especially listing directories and getting and manipulating file attributes.

See above. Everything about rsync was slow, poor thing. I think, in part, because it was trying to emulate remote sync using IPC mechanisms.

[Bulb]

@Steve_The_Cynic said in Audible Manager:

I think, in part, because it was trying to emulate remote sync using IPC mechanisms.

Yup, it probably was. And sockets are not exactly blazingly fast in Windows either.

[dkf]

@Bulb said in Audible Manager:

the windows API provides slightly different information that the POSIX one

The big difference is between fork/execve and CreateProcess.

[PleegWat]

@Bulb said in Audible Manager:

Only relatively though. Windows still suck big time when it comes to working with filesystem, especially listing directories and getting and manipulating file attributes.

Did I ever tell about the time I sped up a function 100x (15 minutes to 10 seconds) by reading from a temp storage in basically a home-grown tar archive instead of a large directory tree of small files?

And that was on linux.

[dcon]

@dse said in Audible Manager:

@dcon said in Audible Manager:

@Steve_The_Cynic said in Audible Manager:

All proper(1) Win32 file APIs

The APIs might. But the odds are strong the programmer is using TCHAR buffer[MAX_PATH]

Win32s

STOP IT. I stopped having those nightmares years ago. NOW YOU'VE DONE IT!

LPTCSTR* buffer[MAX_PAIN];

Dude. Get your types right. That's LPCTSTR. And naming that array buffer is double-evil.

[masonwheeler]

@Bulb said in Audible Manager:

Only relatively though. Windows still suck big time when it comes to working with filesystem, especially listing directories and getting and manipulating file attributes.

How do you figure? I've never had trouble with it...

[Bulb]

@masonwheeler Operations that need to list large number of files, like make or version control status, are rather slow even if you've just done another similar operation shortly before so everything should be hot in the cache.