Skip to content

Add support for over-long filepaths via GNU extension and fix hardlinks #50

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed

Conversation

hasufell
Copy link
Member

@hasufell hasufell commented Feb 21, 2020

Fixes #49 And #51

UTF8 filenames are still broken, but this is not in the scope of this PR. I tested this with the GHC bindist (packing and unpacking).

@hasufell hasufell requested a review from hvr February 21, 2020 22:49
@hasufell hasufell force-pushed the jospald/PR/gnu-tar-long-filenames branch from 7f87a34 to 452f667 Compare February 21, 2020 22:53
@hasufell hasufell changed the title Add support for over-long filepaths via GNU extension Add support for over-long filepaths via GNU extension and fix hardlinks Mar 2, 2020
@hasufell
Copy link
Member Author

hasufell commented Jul 4, 2020

There seems to be no interest of clc or anyone to maintain this package? I've since then forked it and will probably abandon that fork somtime soon in favor of libarchive.

@hasufell hasufell closed this Jul 11, 2020
@gbaz
Copy link

gbaz commented Mar 25, 2021

I'm going to reopen because I sincerly hope this package will get more active maintenance and this should be fixed.

@emilypi
Copy link
Member

emilypi commented Mar 30, 2021

@hasufell My only critique don't think the addition of these brings anything to the table that we can't monomorphize and write directly in Types.hs. Otherwise, I'm happy to merge this when that's done and tests have been added.

@hasufell hasufell force-pushed the jospald/PR/gnu-tar-long-filenames branch from 6a4f311 to db12e9d Compare April 1, 2021 20:05
@hasufell
Copy link
Member Author

hasufell commented Apr 1, 2021

Updated and backported patch from hasufell@8e7b1d5

@hasufell hasufell force-pushed the jospald/PR/gnu-tar-long-filenames branch from 13d4557 to 17efd36 Compare April 1, 2021 20:29
@hasufell hasufell mentioned this pull request Apr 2, 2021
@hasufell
Copy link
Member Author

hasufell commented Apr 2, 2021

Added a fix for #35

@hasufell hasufell force-pushed the jospald/PR/gnu-tar-long-filenames branch 2 times, most recently from a71015f to f2f96cd Compare April 4, 2021 20:06
@hasufell
Copy link
Member Author

hasufell commented Apr 4, 2021

Added fix for #63

@hasufell hasufell force-pushed the jospald/PR/gnu-tar-long-filenames branch 4 times, most recently from b093976 to 8a53ab5 Compare April 5, 2021 10:19
@Bodigrim
Copy link
Contributor

Bodigrim commented Apr 6, 2021

I do not particularly mind depending on These, but the change of signatures is a serious breakage for clients. Could we estimate how disruptive it would be in practice?

@hasufell
Copy link
Member Author

hasufell commented Apr 7, 2021

Could we estimate how disruptive it would be in practice?

I don't know what you mean by that. You'll have to be more specific. That's what PVP is for.

@hasufell hasufell force-pushed the jospald/PR/gnu-tar-long-filenames branch from 8a53ab5 to c067875 Compare April 7, 2021 12:40
@hasufell hasufell force-pushed the jospald/PR/gnu-tar-long-filenames branch from c067875 to 50e6536 Compare April 7, 2021 14:48
@hasufell
Copy link
Member Author

hasufell commented Apr 7, 2021

I don't know what you mean by that. You'll have to be more specific. That's what PVP is for.

I just realized the version is bumped to 0.6.0.0 anyway, so I don't see the point in worrying about public API breakage.

I removed These from most of the internal API, because it's cleaner. But it doesn't make any difference, since the public API changed in toTarPath and it must stay that way.

@hasufell hasufell force-pushed the jospald/PR/gnu-tar-long-filenames branch from 58f1ac6 to be0b663 Compare April 7, 2021 17:53
@Bodigrim
Copy link
Contributor

Bodigrim commented Apr 7, 2021

I don't know what you mean by that. You'll have to be more specific. That's what PVP is for.

Well, this is certainly a major bump according to PVP, but that's not my point. How disruptive is this change for clients (like, cabal-install, stack, hackage-server)? Can they adapt to it in a backward compatible way with a moderate amount of CPP?

@hasufell
Copy link
Member Author

hasufell commented Apr 7, 2021

How disruptive is this change for clients (like, cabal-install, stack, hackage-server)? Can they adapt to it in a backward compatible way with a moderate amount of CPP?

There's nothing disruptive about this. Instead of Either, we're dealing with These. That's pretty straight forward. But the exposed API is a bit brittle anyway.

When These (the constructor) is returned, the caller has to know that they're dealing with long filepaths and need to construct two Entry's. If we improve that, we will break the API even further. The way it is now, the caller can decide to just "ignore" this case and treat it like an error, like before (which is sorta backwards-compatible).

@hasufell
Copy link
Member Author

hasufell commented Apr 7, 2021

I just built cabal-install with this branch. All it took was:

--- a/cabal-install/src/Distribution/Client/SrcDist.hs
+++ b/cabal-install/src/Distribution/Client/SrcDist.hs
@@ -62,8 +62,9 @@ packageDirToSdist verbosity gpd dir = do
             let prefix = prettyShow (packageId gpd)
             modify (Set.insert prefix)
             case Tar.toTarPath True prefix of
-                Left err -> liftIO $ die' verbosity ("Error packing sdist: " ++ err)
-                Right path -> tell [Tar.directoryEntry path]
+                Tar.This err -> liftIO $ die' verbosity ("Error packing sdist: " ++ show err)
+                Tar.These err _ -> liftIO $ die' verbosity ("Error packing sdist: " ++ show err)
+                Tar.That path -> tell [Tar.directoryEntry path]
 
             for_ files $ \file -> do
                 let fileDir = takeDirectory (prefix </> file)
@@ -72,13 +73,15 @@ packageDirToSdist verbosity gpd dir = do
                 when needsEntry $ do
                     modify (Set.insert fileDir)
                     case Tar.toTarPath True fileDir of
-                        Left err -> liftIO $ die' verbosity ("Error packing sdist: " ++ err)
-                        Right path -> tell [Tar.directoryEntry path]
+                        Tar.This err -> liftIO $ die' verbosity ("Error packing sdist: " ++ show err)
+                        Tar.These err _ -> liftIO $ die' verbosity ("Error packing sdist: " ++ show err)
+                        Tar.That path -> tell [Tar.directoryEntry path]
 
                 contents <- liftIO . fmap BSL.fromStrict . BS.readFile $ dir </> file
                 case Tar.toTarPath False (prefix </> file) of
-                    Left err -> liftIO $ die' verbosity ("Error packing sdist: " ++ err)
-                    Right path -> tell [(Tar.fileEntry path contents) { Tar.entryPermissions = Tar.ordinaryFilePermissions }]
+                    Tar.This err -> liftIO $ die' verbosity ("Error packing sdist: " ++ show err)
+                    Tar.These err _ -> liftIO $ die' verbosity ("Error packing sdist: " ++ show err)
+                    Tar.That path -> tell [(Tar.fileEntry path contents) { Tar.entryPermissions = Tar.ordinaryFilePermissions }]
 
     entries <- execWriterT (evalStateT entriesM mempty)
     let -- Pretend our GZip file is made on Unix.

To support over-long filepaths, the patch is as follows:

--- a/cabal-install/src/Distribution/Client/SrcDist.hs
+++ b/cabal-install/src/Distribution/Client/SrcDist.hs
@@ -62,8 +62,9 @@ packageDirToSdist verbosity gpd dir = do
             let prefix = prettyShow (packageId gpd)
             modify (Set.insert prefix)
             case Tar.toTarPath True prefix of
-                Left err -> liftIO $ die' verbosity ("Error packing sdist: " ++ err)
-                Right path -> tell [Tar.directoryEntry path]
+                Tar.This err -> liftIO $ die' verbosity ("Error packing sdist: " ++ show err)
+                Tar.These _ path -> tell [Tar.longLinkEntry prefix, Tar.directoryEntry path]
+                Tar.That path -> tell [Tar.directoryEntry path]
 
             for_ files $ \file -> do
                 let fileDir = takeDirectory (prefix </> file)
@@ -72,13 +73,15 @@ packageDirToSdist verbosity gpd dir = do
                 when needsEntry $ do
                     modify (Set.insert fileDir)
                     case Tar.toTarPath True fileDir of
-                        Left err -> liftIO $ die' verbosity ("Error packing sdist: " ++ err)
-                        Right path -> tell [Tar.directoryEntry path]
+                        Tar.This err -> liftIO $ die' verbosity ("Error packing sdist: " ++ show err)
+                        Tar.These _ path -> tell [Tar.longLinkEntry fileDir, Tar.directoryEntry path]
+                        Tar.That path -> tell [Tar.directoryEntry path]
 
                 contents <- liftIO . fmap BSL.fromStrict . BS.readFile $ dir </> file
                 case Tar.toTarPath False (prefix </> file) of
-                    Left err -> liftIO $ die' verbosity ("Error packing sdist: " ++ err)
-                    Right path -> tell [(Tar.fileEntry path contents) { Tar.entryPermissions = Tar.ordinaryFilePermissions }]
+                    Tar.This err -> liftIO $ die' verbosity ("Error packing sdist: " ++ show err)
+                    Tar.These _ path -> tell [Tar.longLinkEntry (prefix </> file), Tar.directoryEntry path]
+                    Tar.That path -> tell [(Tar.fileEntry path contents) { Tar.entryPermissions = Tar.ordinaryFilePermissions }]
 
     entries <- execWriterT (evalStateT entriesM mempty)
     let -- Pretend our GZip file is made on Unix.

@hasufell hasufell force-pushed the jospald/PR/gnu-tar-long-filenames branch from 678cfe0 to 9b5970c Compare April 7, 2021 19:57
@cartazio
Copy link

cartazio commented Apr 8, 2021

What are the current action items needed to get this patch over the last few ready to merge hump? I’m happy to help however is needed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

fails to unpack a ghc bindist properly
5 participants