> 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.
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).
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
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".
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.
> 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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
69 comments
[ 3.4 ms ] story [ 86.0 ms ] threadJust saying...
It has so many ways to diff, and a great cherry-picking UI.
Drink Verification Can to Push. Rebase is for Windows Pro subscribers only. 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.
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.
Remember left click ? Remember when your drives were in My Computer ?
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.
https://www.elevenforum.com/t/turn-on-or-off-app-execution-a...
https://superuser.com/questions/1728816/manage-windows-app-e...
No thank you. I'm happy with Microsoft having nothing to do with my Git.
[1] https://en.m.wikipedia.org/wiki/Embrace,_extend,_and_extingu...
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.
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.
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.
> 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.
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.
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:
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.Years ago I would be happy for such a feature, now I'm worried.
It is for your protection. /s
(They do eventually restart automatically, but still.)
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
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.
3. Pushing you towards paid MS SaaS tools (prominently OneDrive)
Also since then we've experienced much worse, so we laugh at the shit we used to complain about.
Dev: "Remember when we fought because you wouldn't give me source code?"
MSFT: "Yeah. To be honest I didn't even have the source code for half the stuff you wanted."
Dev: "Well, nowadays I'm lucky if I even get a binary."
MSFT: "Why didn't we think of that? Maybe we can turn office into a cloud service..."
I hope regular windows users start using git more often because of this. It'd be pretty killer in an office setting.
so, it is either a bug, a mock screenshot or an intriguing feature.
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.