Windows File Explorer will be more powerful with version control and 7z | Hacker News Reader

Windows File Explorer will be more powerful with version control and 7z

theverge.com

48 pointsbenkan66 comments

> The Windows file navigator will natively interface with your Git and offer more file compression.

No thank you. I'm happy with Microsoft having nothing to do with my Git.

Those points to somebody at Microsoft wanting to show impact and have promotions.

I'm reasonably certain their actions will have an impact, not sure about that promotion, though.

embraceExtendextuinguish to opt out just complete this hazard obstacle course. Every day. St. Choice watches you suffer in regedit bureaucracy while enjoying the free market

GitLab user, then?

It asked for my phone number and bank card to register. No, thank you.

Yes. Gitlab for dotfiles and public repos, gitea for private repos.

They already do, by owning the biggest supporting Platform: GitHub, though I hope the recent trend of embracing open source is triple E[1] without the "extinguish".

[1] https://en.m.wikipedia.org/wiki/Embrace,_extend,_and_extingu...

Only if you use github. git is a protocol, not a website.

Right, github is a frontend for git, which is what the File Explorer would be

Next stop: GitHub git will be enhanced and only fully work with Windows Explorer git

Don't forget Microsoft Account for the best experience!

The biggest supporting platform is sshd. I wish Microsoft the best in their efforts.

I'd be happy with File Explorer not giving the circle of death and the green bar of despair on a regular basis. Microsoft, can you fix these basic usability problems first before shoving more bloat into the tool?

I'd be happy if it just didn't take the taskbar and start menu with it when it crashed. Why are they so intertwined?

(They do eventually restart automatically, but still.)

fwiw, there is an option to spawn explorer windows in separate processes. I always turn it on for that reason.

I had no idea. I am sure it is disabled on my corporate laptop, but definitely worth checking out tomorrow.

I love when I accidentally happen to drag a file over disconnected network drive and whole explorer freezes for 30 seconds...

This.

It never fails to amuse me that the "exciting" things that Microsoft does to Windows always falls into one of two categories:

1. Implementing features that have been available in Linux/MacOS for years

2. Adding interoperability capabilities

I'm happy Microsoft is slowly catching up with the times, but it's still not a good look

> I'm happy Microsoft is slowly catching up with the times

If that includes web pages as GUI, then I'm NOT happy.

I wish Linux would catch up to Win3.1 GDI32, COMCTL, MFC & OLE.

Don't forget,

3. Pushing you towards paid MS SaaS tools (prominently OneDrive)

> Microsoft says it’s also letting File Explorer natively compress files to 7-zip and TAR; currently, the right-click context menu has a “Compress to ZIP file” option, but ZIP is thought to be a bit antiquated in terms of how much compression you get.

ZIP is antiquated...but TAR isn't?

> ZIP is antiquated...but TAR isn't?

No, because tar only does archiving and is usually combined with a separate compressor - gzip, bzip2, lzip, and no doubt new and exciting compressors that have yet to be invented. So tar (with a suitable modern compressor) is still relevant today.

I agree, that it is antiquated.

> suitable modern compressor

I would expect a suitable modern compressor to handle files by itself and fail to handle file related things if given a tar archive.

Block based compressors like gzip, bzip2, xz, lzma, etc don’t natively know how to compress multiple files, to them it’s just bytes in bytes out. Using these with tar allows both archive (multiple files / directories in one file) as well as compression. Such usage has the potential for higher compression ratios because it can deduplicate across the entire archive. Zip compresses each file individually, but has an uncompressed index. Tools like 7z use standard compression algorithms (I believe Lzma) with a different archive format. It’s all about how you want to integrate or customize your tools.

Tar isn't a great archival (by which I mean combining multiple files into one file) format for most people, since it emulates tape by putting records of what file you just read right in line with the data. To access a single file from a tar, you have to read the archive sequentially until you get to the record for that file. (assuming there's only one copy of that file in there)

Most other formats put data about what files are contained inside at the end of the file, so you need to read much less of it.

Being able to append tar files together is a killer feature though, and it's not going anywhere.

Another feature of tar (the 7-zip implementation, anyway, I haven't checked others) is that it will properly archive files whose path length exceeds the path length limit, and then also restore the files properly. Conversely, trying to zip up a group of files with paths too long appears to work but then results in a corrupt zip file that will not unzip. I'm no expert in this area, but that is my recollection. So if you have any doubts about whether your files to archive have paths too long it is better to tar them then zip the tar file rather than just zip the files.

Well now you got me curious...

I don't know about particular implementations, but tar should support 255-character file names, with the caveat that I'm pretty sure that length includes the path (i.e. 'foo/bar.txt' is 11 chars long, it doesn't matter that 3 are in the directory prefix, and also the separating / chars do count). You can see this by reading the file format spec, ex. https://www.ibm.com/docs/en/zos/3.1.0?topic=formats-tar-form... is my personal favorite. Pretty much everyone is using the extended USTAR format, and then the overall file path+name is stored in the name field and if it's longer than 100 chars then the prefix field is used, so you get a max of 155+100=255 chars, which is probably sufficient since IIRC most moderns systems won't let you make a longer path than that on the live filesystem anyways.

I'm less familiar with zip, but https://en.wikipedia.org/wiki/ZIP_(file_format)#File_headers seems to say that the file name field is arbitrary, but the file name length field is 2 bytes. A little searching also turns up https://pkwaredownloads.blob.core.windows.net/pkware-general... which appears to be the official spec, which contains this:

    4.4.10 file name length: (2 bytes)
    4.4.11 extra field length: (2 bytes)
    4.4.12 file comment length: (2 bytes)

        The length of the file name, extra field, and comment
        fields respectively.  The combined length of any
        directory record and these three fields SHOULD NOT
        generally exceed 65,535 bytes.  If input came from standard
        input, the file name length is set to zero.

so my reading is actually that zip should support very long file paths. Of course, I would easily believe that in practice tar implementations handle long paths better, because software is like that.

Tarballing files if you're not gzipping, bzipping, or 7zipping them is a bit antiquated, but being able to natively open tarballs in Windows would be kind of cool.

Wow, a pragmatic user-benefiting feature being added to Windows? That's certainly a breath of fresh air.

There must be a way to scrape some shareholder value out of the feature.

Drink Verification Can to Push. Rebase is for Windows Pro subscribers only. Merge Right After this Ad!

Probably just pushing you towards GitHub.

>Merge Right After this Ad!

I'd love to see this actually. I'm wondering just how many people would actually put up with it.

Drives users to Github. Is MSFT still reporting monthly user counts?

> Drink Verification Can to Push. Rebase is for Windows Pro subscribers only. Merge Right After this Ad!

While having git built into file explorer would be welcome, I'd rather it be limited to mostly read-only actions, with nice indicators (tracked/untracked/modified). The only real write-action would be to add/remove files to the index.

I don't want a bug in explorer mangling my git repo and pushing the changes.

They will, as usual, remove some features, to compensate.

Remember left click ? Remember when your drives were in My Computer ?

How many Git integration will benefit? 0.1% of windows users? Git is one of those things devs are capable to manage theirself, updating when needed etc. A faster File Explorer or a taskbar that doesn't suck (open faster, movable on the side, calendar on all screen, removable recommendations...) would benefit many more.

I’m happy at the same time scared. Please don’t corrupt my git repo.

Happy to see windows adding useful developer focused feature.

Makes sense for file explorer to understand everything.

If Microsoft really wanted, they could Sherlock everything.

Given how they hijack paths with the WindowsApps\Python.exe, I am not hopeful. I have to handhold people setting up Python on Windows so they don't end up with the app store version, and they don't get their paths crossed and end up pip installing things in a version they don't use. It's seriously awful and the only solution is to delete the whole WindowsApps folders (safe to do, it just contains stubs).

The safer way is to disable the app execution aliases.

Thanks! Found these: (UI and Powershell)

https://www.elevenforum.com/t/turn-on-or-off-app-execution-a...

https://superuser.com/questions/1728816/manage-windows-app-e...

My experience with the new compression formats they added to Explorer has not been great, overall performance is poor, larger files get stuck and it straight up can't extract some perfectly valid files. I'm wary of more integrations if they didn't polish something that regular people may use daily

It’s great to add support for 7z and such, but there may be a problem.

My friends in game dev frequently work with large files. They often bundle and compress them for storage and sharing. They were happy to hear that Windows would add support for these formats directly rather than requiring third party software to get the job done.

Sadly, the people who tried it reported back that the Windows-provided functionality was incredibly slow. When working with files of immense size like they do, using the official Windows compression and decompression was costing them significantly more time looking at progress bars than the third party apps.

If this is true in the final stable release, then what’s the point of adding the feature at all? It only helps out people who rarely use those compression formats, and only work with smaller files.

How about not two sets of common folders e.g Documents from true dreadful “This PC” and Documebts from c:\users\name\Documents

Or retaining settings, I swear every time I set file view to detailed it goes back to something else.

I’d have no problem switching file managers, but like everything bolted on Windows, it has higher ordinance.

Don't forget the onedrive version of these folders I never asked for either. It may have been installed by my corporate overlord, but still, talk about muddled design.

> How about not two sets of common folders e.g Documents from true dreadful “This PC” and Documebts from c:\users\name\Documents

They are working hard on this feature. They want all you files in OneDrive so the NSA can search them freely, without the need to connect to your computer.

There's a lot of things the file explorer needs. Git is not one of them.

Millions (or however many) devs and managers installing TortoiseGit in Windows-first shops would beg to differ.

Maybe this will break tortoisegit AND your local git.

Years ago I would be happy for such a feature, now I'm worried.

They don't implement old requirements. They only implement the new ones. /s

There is just no way I would trust any change Microsoft makes at this point. They will abuse their position to violate your privacy. Consent means nothing to these shameless monopolists.

You consented when you installed Windows.

It is for your protection. /s

Fun fact: according to the screenshot, the .git directory itself is versioned...

so, it is either a bug, a mock screenshot or an intriguing feature.

This post seems to be over a month old, I wonder when this feature is coming.

I hope regular windows users start using git more often because of this. It'd be pretty killer in an office setting.

I can't wait Disk Voyager to come out so I can ditch File Explorer - https://www.diskvoyager.com

https://tortoisegit.org/

Just saying...

Oh my gosh, TortoiseSVN and TortoiseCVS. Now that's a blast from the past. Wow.

That's my daily driver

Yep, donated.

It has so many ways to diff, and a great cherry-picking UI.

Yeah, that's proof there's a need for Git integration in Explorer.

Windows has been for years corrupting files unzipped via explorer. I am not going to trust them with 7-zip now.

Is there a particular known issue you’re referring to? I’m curious, I’ve never seen that behavior.

We had some zip files that if content was unzipped with 7-zip the files were correct but not if unzipped with Windows explorer. I am struggling to remember what were the contents of the zip files I think it was some data that was loaded by our or third party application what would produce a crash if not unzipped correctly. I never got to the root cause because coworker told me to "fix" it by using 7-zip and was not bothered by it since then, only when I passed the knowledge to newer coworkers. It was happening still on Windows 10.

The zip/tar.gz support is just slow. It's just another thing that you'll have to manually disable now.

Reply on news.ycombinator.com