Skip to content
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

Issues with getEntry() and removeEntry() on Windows environment #27

Closed
FreakyBytes opened this issue Jan 30, 2017 · 0 comments
Closed

Comments

@FreakyBytes
Copy link
Member

Trac Ticket #25

component: code
owner: Martin Scharm martin@binfalse.de
reporter: sdeshmukh@mango-solutions.com
created: 2015-03-06 10:32:51
milestone:
type: task
version:
keywords:

CombineArchive v0.9.4.4 :

The functionality getEntry() and removeEntry() (with "location" or "entry" as parameter) doesn't work for '''Windows''' based system and they don't show any error or exceptions either.

The Steps to reproduce,

  1. Create combine archive and add a file as entry to it.

  2. Save and close this combine archive to file system.

  3. Open this existing combine archive.
    4 a.Try to access entry ( getEntry() or removeEntry() ) using its relative file path.
    4 b. Try to access entry ( getEntry() or removeEntry() ) using valid Archive Entry.

  4. The access to entry is not possible and these methods return failure ("null" in case of getEntry() and "false" for removeEntry()).

The unit test for this issue is added to "TestArchive.java" from CombineArchive codebase locally and patch is attached with the ticket.

The initial analysis suggests that this issue is related with handling File separators during reading and accessing archive for different file systems.

comment 1

time: 2015-03-06 10:33:36
author: sdeshmukh@mango-solutions.com

Updated attachment to TestCombineArchive.patch

comment 2

time: 2015-03-06 10:33:36
author: sdeshmukh@mango-solutions.com

archive unit test patch

comment 3

time: 2015-04-21 10:00:05
author: Martin Scharm martin@binfalse.de

In None:


added unit test by sdeshmukh@.. [see #25]

comment 4

time: 2015-04-22 12:21:33
author: Martin Scharm martin@binfalse.de

In None:


started wotking on win bug [see #25]

spotted the problem: win is a bit incosistent wit paths?

when working with paths from a zipfs i get slashes ('/'), that means
{{{
zipfs.getPath (location).normalize ()

results in something like /path/to/file.

but (almost) every other path will contain backslashes (''), so

Paths.get (about).normalize ()

will give me \path\to\file.

oviously, comparing these two fails...

i already implemented a pathFixer` in the `Utils class which
replaces the os' path seperator with a slash, to make sure we
always work with slashes. that should hopefully be able to fix
that problem. still need to find out where to fix the paths..
}}}

comment 5

time: 2015-04-22 12:21:49
author: Martin Scharm martin@binfalse.de

In None:


applied the path fixer.. [fixes #25]

that should fix the slash/backslash problem.
had to adjust the test, because the test will
now fail on slash-based-systems.

comment 6

time: 2015-04-22 12:21:49
author: Martin Scharm martin@binfalse.de

Updated owner to Martin Scharm martin@binfalse.de

comment 7

time: 2015-04-22 12:21:49
author: Martin Scharm martin@binfalse.de

Updated resolution to fixed

comment 8

time: 2015-04-22 12:21:49
author: Martin Scharm martin@binfalse.de

Updated status to closed

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

No branches or pull requests

1 participant